From vszocs at redhat.com  Tue Oct  2 16:01:04 2012
From: vszocs at redhat.com (Vojtech Szocs)
Date: Tue, 2 Oct 2012 12:01:04 -0400 (EDT)
Subject: [Engine-devel] Frontend questions.
In-Reply-To: <505B63F5.1080300@redhat.com>
Message-ID: <849895112.3758916.1349193664322.JavaMail.root@redhat.com>

Hi guys,

> this should be easy enough to launch another window with the requested url.

Indeed, but you might also want to override UI logic for handling "open console" functionality for VNC protocol in WebAdmin:

[in MainTabVirtualMachineView, around line 223 that adds ConsoleModel-bound action button]

getTable().addActionButton(... {

  @Override
  protected UICommand resolveCommand() {
    ConsoleModel defaultConsoleModel = getMainModel().getDefaultConsoleModel();
    final UICommand defaultConnectCommand = defaultConsoleModel != null ? defaultConsoleModel.getConnectCommand() : null;

    if (defaultConnectCommand != null && defaultConsoleModel instanceof VncConsoleModel) {
      // Replace default VncConsoleModel's Connect command with custom functionality
      return new UICommand("Connect", null) {

        @Override
        public boolean getIsAvailable() {
          return defaultConnectCommand.getIsAvailable();
        }

        @Override
        public boolean getIsExecutionAllowed() {
          return defaultConnectCommand.getIsExecutionAllowed();
        }

        @Override
        public void Execute(Object... parameters) {
          if (!getIsAvailable() || !getIsExecutionAllowed()) {
            return;
          }
          WebUtils.openUrlInNewWindow("Custom popup window title", "url from novnc-server");
        }

    };
  } else {
    return defaultConnectCommand;
  }

});

Regards,
Vojtech


----- Original Message -----
From: "Itamar Heim" <iheim at redhat.com>
To: snmishra at linux.vnet.ibm.com
Cc: "Ohad Levy" <ohadlevy at redhat.com>, "Vojtech Szocs" <vszocs at redhat.com>, engine-devel at ovirt.org, "Adam Young" <ayoung at redhat.com>
Sent: Thursday, September 20, 2012 8:44:05 PM
Subject: Re: [Engine-devel] Frontend questions.

On 09/19/2012 06:51 PM, snmishra at linux.vnet.ibm.com wrote:
>
> Hi,
>
>
>      I am looking at adding support for novnc in ovirt. I have not
> worked on the frontend and thought of asking some questions to the list
> to save time.
>
>      Currently, when a user selects to open console on a VM with VNC.
> They get a popup window with IP, port and password for VNC session. I
> plan to take this info to host and run the command -
>
>    novnc_server --vnc IP:(port-5900)
>
> This command returns a URL, use this url to open a new browser window
> which will be a vnc session to the VM.
>
>     My questions are -
>
> 1. How to run the novnc-server command on the host?

i can't say i like the idea of launching these on the engine, but we can 
start with making this work first with these limitations. hopefully 
these aren't too resource intensive.
ohad - how do you deal with this in foreman?
adam - i saw you pushed these rpms to fedora - can you share how this is 
launched in openstack?

on the technical side, you can launch an external process with the 
relevant parameters.
though we probably need to consider how we could do this not via shell 
locally, rather via a remote call to allow setting this up on another 
server than the engine.


>
> 2. How to open a new URL for VNC session?

this should be easy enough to launch another window with the requested url.
vojtech?

>
> Thanks
> Sharad Mishra
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel




From simon at redhat.com  Tue Oct  2 17:36:44 2012
From: simon at redhat.com (Simon Grinberg)
Date: Tue, 2 Oct 2012 13:36:44 -0400 (EDT)
Subject: [Engine-devel] RFE: Netwrok Main Tab
In-Reply-To: <1814574.41.1348474429144.JavaMail.atal@atal-fedora.tlv.redhat.com>
Message-ID: <606596814.5345274.1349199404659.JavaMail.root@redhat.com>

Trying to sum up some of the suggestions ('coincidently' dropping those which I think a bit too much for first implementation :)) and add some suggestions of my own 

1. On the hosts subtab:
   1.1 Have a radio button that will show either 
       1.1.1 All the hosts that this network is attached to
       1.1.2 All the hosts where this network attached to the cluster but not to the host (Very important for non-required where the host status does not indicate something is missing)
   1.2 Have a remove button for 1.1.1, ManageNetworks button for 1.1.2. Simple add will not do since you don't know where to add. 

2. On the vms subtab 
   2.1 Have a radio button that will show either 
       2.1.1 All the vms that this network is attached to
       2.1.2 All the vms where this network is not attached to
   2.2 Have a 'remove' button for 2.1.1, Have 'add' button for 2.1.2
   2.3 Allow multiple selection for both actions of 2.2
   2.4 Add remove from all button. 
   2.5 I would not bother to show all the nics attached to the VM from the same network, it's too rare. Just make sure there is no exception if this does exist. So the columns should have 'nic' as the first and there should be only one VM per line. If there are more then one nic per VM then just indicate 'multiple' 

3. Templates subtab - same as VM, drop the expansion of the NICs list.

4. Clusters subtab
   Allow assign to multiple clusters - same as the edit in the data center tab (Just use the same dialogue)

5. Main: You have enough space then why not add the MTU column?

6. Queries for the sub tabs: For each needs the reverse query as well (Probably more important when adding new network)  


Oops, I think I mostly added and dropped (almost) nothing :)   

Regards,
Simon
 

----- Original Message -----
> From: "Avi Tal" <atal at redhat.com>
> To: "Yaniv Kaul" <ykaul at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Monday, September 24, 2012 10:13:52 AM
> Subject: Re: [Engine-devel] RFE: Netwrok Main Tab
> 
> 
> 
> ----- Original Message -----
> > From: "Yaniv Kaul" <ykaul at redhat.com>
> > To: "Moti Asayag" <masayag at redhat.com>
> > Cc: engine-devel at ovirt.org
> > Sent: Sunday, September 23, 2012 6:16:47 PM
> > Subject: Re: [Engine-devel] RFE: Netwrok Main Tab
> > 
> > On 09/23/2012 06:12 PM, Moti Asayag wrote:
> > > On 09/23/2012 05:01 PM, Yaniv Kaul wrote:
> > >> On 09/23/2012 04:55 PM, Alona Kaplan wrote:
> > >>> ----- Original Message -----
> > >>>> From: "Avi Tal" <atal at redhat.com>
> > >>>> To: "Alona Kaplan" <alkaplan at redhat.com>
> > >>>> Cc: engine-devel at ovirt.org
> > >>>> Sent: Sunday, September 23, 2012 4:17:26 PM
> > >>>> Subject: Re: [Engine-devel] RFE: Netwrok Main Tab
> > >>>>
> > >>>>
> > >>>>
> > >>>> ----- Original Message -----
> > >>>>> From: "Alona Kaplan" <alkaplan at redhat.com>
> > >>>>> To: "Avi Tal" <atal at redhat.com>
> > >>>>> Cc: engine-devel at ovirt.org
> > >>>>> Sent: Sunday, September 23, 2012 1:31:32 PM
> > >>>>> Subject: Re: [Engine-devel] RFE: Netwrok Main Tab
> > >>>>>
> > >>>>> 1. What actions do you suggest to add?
> > >>>> Add, Edit and remove actions of each component.
> > >>>>
> > >>> Host:
> > >>> Add- What will add action on Networks->Hosts sub tab do? Choose
> > >>> an
> > >>> existing host and attach the network to one of its nics?
> > >>> How will it work? after choosing the host you will open
> > >>> setupNetworks
> > >>> window and just enable dragging of the selected network (in the
> > >>> main
> > >>> tab) to a nic? I think it is too much.
> > >>>
> > >>> Edit- same as add.
> > >>>
> > >>> Remove- What is the meaning of Remove host in network's
> > >>> context?
> > >>> The
> > >>> network will be detached from the host? I think it is
> > >>> confusing.
> > >>>
> > >>> Vm/Template:
> > >>> Add: What will it do? You will choose a vm and then add a vnic
> > >>> to
> > >>> the
> > >>> vm? Where will you see the vnic details?
> > >>> Edit: Same as add.
> > >>> Remove: You will remove all the vnics that use the selected
> > >>> network
> > >>> from the vm? Or do you mean to add a remove per vnic?
> > >> For all the above: yes.
> > >> We can certainly work on the small details, but having a main
> > >> tab
> > >> with
> > >> little to no action whatsoever is kinda disappointing.
> > > IMO adding 'assign' action in the main tab might be handy in
> > > order
> > > to
> > > assign a single network in a single dialog to several clusters.
> > >
> > > However It is not clear to me how Add/Edit for a VM in a sub-tab
> > > should
> > > look like. The VM should have a list of interfaces (represented
> > > as
> > > sub
> > > collection/tree).
> > 
> > I was thinking more of right-click on the network, selecting 'Add
> > to
> > VM'
> > and then selecting single/mutliple VMs from a dialog with all the
> > VMs
> > (yes, filtered via search).
> > Y.
> > 
> 
> +1
> 
> > > What will be the meaning of 'Add' in that context? Since the VM
> > > already
> > > have a vNIC attached to that network. If adding another once, it
> > > should
> > > be enabled on the record representing the VM itself which will
> > > confuse
> > > the user.
> > > Same goes for 'Edit' of a VM interface under a context of a
> > > specific
> > > network: in the current 'Edit VM Interface' you can change the
> > > network.
> > > Should the same dialog be used here as well?
> > >
> > > The 'Remove' option is the clearer action on this context.
> > >
> > >
> > >> (example of 'small details' - yes, when clicking remove for a
> > >> VM/template - it will remove all vNICs that use that network
> > >> from
> > >> the
> > >> VM. A VM with more than one vNIC on the same network is not the
> > >> common
> > >> case anyway, and if you want to remove just a single vNIC, go to
> > >> the
> > >> VM). I think we can also live with Add/Remove only, and 'defer'
> > >> the edit
> > >> actions to the respectable objects (host/vm/template) edit
> > >> dialog
> > >> boxes
> > >> that originates from their own main tab.
> > >>
> > >> Y.
> > >>
> > >>>>> 2. I don't understand your suggestion. You mean add
> > >>>>> SetupNetworks
> > >>>>> to
> > >>>>> the Networks main tab?
> > >>>> No.
> > >>>> Just Thinking of a nice display which will present logical
> > >>>> network
> > >>>> and his connected host/vm configuration instead of passing
> > >>>> through
> > >>>> dub-tabs
> > >>>> I should give it a deeper thought.
> > >>>>
> > >>>>
> > >>>>> ----- Original Message -----
> > >>>>>> From: "Avi Tal" <atal at redhat.com>
> > >>>>>> To: "Alona Kaplan" <alkaplan at redhat.com>
> > >>>>>> Cc: engine-devel at ovirt.org
> > >>>>>> Sent: Thursday, September 20, 2012 6:58:05 PM
> > >>>>>> Subject: Re: [Engine-devel] RFE: Netwrok Main Tab
> > >>>>>>
> > >>>>>> 1. Why not having Actions for Hosts, Vms and Templates ?
> > >>>>>> I believe we should have those actions instead of making the
> > >>>>>> user
> > >>>>>> browse between 'network -> vms -> network (sub tab)' just in
> > >>>>>> order
> > >>>>>> to update VM's network.
> > >>>>>>
> > >>>>>> 2. Why having such a big window which most of the time will
> > >>>>>> be
> > >>>>>> empty?
> > >>>>>>      How many logical network would be existed in the
> > >>>>>>      system?
> > >>>>>>      My suggestion is to go for more graphical window which
> > >>>>>>      will
> > >>>>>>      present:
> > >>>>>>      A. logical networks
> > >>>>>>      B. Multiple networks with the host configurations at
> > >>>>>>      the
> > >>>>>>      same
> > >>>>>>      window: very important because most of the System
> > >>>>>>      admins
> > >>>>>>      would
> > >>>>>>      like to have a bigger picture of the entire network
> > >>>>>>      configuration
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>> ----- Original Message -----
> > >>>>>> From: "Alona Kaplan" <alkaplan at redhat.com>
> > >>>>>> To: engine-devel at ovirt.org
> > >>>>>> Sent: Thursday, September 20, 2012 1:50:15 PM
> > >>>>>> Subject: [Engine-devel] RFE: Netwrok Main Tab
> > >>>>>>
> > >>>>>> Hi all,
> > >>>>>>
> > >>>>>> Please review the wiki and add your comments.
> > >>>>>>
> > >>>>>> http://wiki.ovirt.org/wiki/Feature/NetworkMainTab
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>> RFE:
> > >>>>>> https://bugzilla.redhat.com/858742
> > >>>>>>
> > >>>>>> Thanks,
> > >>>>>> Alona.
> > >>>>>> _______________________________________________
> > >>>>>> Engine-devel mailing list
> > >>>>>> Engine-devel at ovirt.org
> > >>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> > >>>>>>
> > >>> _______________________________________________
> > >>> Engine-devel mailing list
> > >>> Engine-devel at ovirt.org
> > >>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> > >> _______________________________________________
> > >> Engine-devel mailing list
> > >> Engine-devel at ovirt.org
> > >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From vszocs at redhat.com  Tue Oct  2 18:46:51 2012
From: vszocs at redhat.com (Vojtech Szocs)
Date: Tue, 2 Oct 2012 14:46:51 -0400 (EDT)
Subject: [Engine-devel] UI Plugins: PoC patch revision 5 is here
In-Reply-To: <D290AD8432118048947689BA3AE8A9B3E47B82@SACEXCMBX04-PRD.hq.netapp.com>
Message-ID: <343178476.3896355.1349203611681.JavaMail.root@redhat.com>

Hi Chris, 

many thanks for your feedback and suggestions :) 

Adding context-sensitive button with corresponding menu item sounds good! In fact, this is the proper way how context menu items should be handled, since WebAdmin data grids work with context-sensitive "action buttons" which are reflected within the context menu. I agree that this is a very useful feature to have in plugin API, it should be implemented as part of next major PoC revision. 

I have a question though: when the user clicks the custom button or corresponding context menu item, will your plugin handle common dialog UI (everything except actual content) on its own, or do you prefer to have some kind of "dialog UI" API to create the standard-looking dialog frame for you? I like the idea of using iframe to present custom content though :) 

As for grouping multiple context-sensitive buttons and corresponding context menu items, this makes sense and we have something like this already implemented in WebAdmin (in Host main tab, Power Management drop-down group button, but this is defined not to appear in context menu though). I think this should be part of "custom context-sensitive button / menu item" plugin API feature. 

> If needed we can help work on an implementation for the dialog popup plugin framework as we?d like to get it in relatively quickly so we can move forward on the content side of our plugin. 

If I understand correctly, this is about providing "dialog UI" API to create the standard-looking dialog frame + custom content iframe. I'd like to help with this as well, but you can play with the code and propose a patch on top of PoC rev.5 [http://gerrit.ovirt.org/8120]. 

> For the reverse proxy, would it be easier from a customer standpoint to just include a reverse proxy servlet such as this one? 

Actually, I was under the impression that oVirt Engine (3.1) package (ovirt-engine) takes care of setting up Apache web server, which redirects all traffic to Engine JBoss AS by default (but maybe I am wrong here). However, if this is the case, an efficient way to work around same-origin policy (cross-origin issues) is to configure Apache's reverese proxy module (mod_proxy), as discussed in another thread on engine-devel: http://lists.ovirt.org/pipermail/engine-devel/2012-September/002511.html 

This way, you could use Apache to bring Engine and arbitrary (local or remote) web services on same origin. What do you think? 

On the other hand, using a special-purpose reverse proxy servlet directly in Engine, not sure if that's a good idea though.. (I'd prefer configuring "front-end" web server, such as Apache, for this purpose) 

I'm also sending a couple of updates: 

UI Plugins Follow-Up Meeting: scheduled for Tuesday, October 9 at 4pm GMT+1 (I'll send a meeting invitation soon, also planning to re-write oVirt UI Plugins wiki soon after that) 

PoC rev.5 patch update: many thanks to Juan and Doron for reviewing the recent patch [http://gerrit.ovirt.org/8120]! I'll update the patch accordingly as revision 5.1 

Planned items to be included in PoC revision 6: 

    * adding custom context-sensitive button (either separately or within a button group), along with corresponding context menu item representation 
    * update custom main tab to show the actual content (iframe) from the given URL 
    * adding custom sub tab that shows content from the given URL 



More items to consider having in PoC revision 6: 


    * "dialog UI" API to create the standard-looking dialog frame + custom content iframe 
    * Engine REST API exposed through plugin API 
    * integration with Tasks pane to provide visual feedback on custom operations 
    * extending existing dialogs (e.g. Edit Cluster Policy - custom properties) 



Let me know what you think. 



Regards, 
Vojtech 


----- Original Message -----

From: "Christopher Morrissey" <Christopher.Morrissey at netapp.com> 
To: vszocs at redhat.com 
Cc: "George Costea" <George.Costea at netapp.com>, "Dustin Schoenbrun" <Dustin.Schoenbrun at netapp.com>, engine-devel at ovirt.org 
Sent: Tuesday, October 2, 2012 6:15:34 PM 
Subject: RE: [Engine-devel] UI Plugins: PoC patch revision 5 is here 



Hi Vojtech, 

The patch is great and has cleared up some questions I had about the implementation. I?ve been able to get the sample plugins working and waded through the code changes, so feel like I have a good understanding of what was delivered. Thanks a lot for putting this all together. I do have a few questions and suggestions for you, though. 

Will there eventually be a way to add one or more buttons to the context sensitive buttons and menus throughout the interface? For example, we?d like to allow a button to provision a datastore when a data center, cluster, or host is selected. When the button is clicked, it would open a dialog with an iframe in which we would load our interface to perform the associated action. Some contexts would have several buttons, such as a storage domain (provision, resize, dedupe management, destroy) so it would probably make sense for a drop down menu to be available as well so that the number of buttons above the table doesn?t get too cluttered. We?d also like to add these same actions to the menus that popup when a contextual object is right clicked. 

If needed we can help work on an implementation for the dialog popup plugin framework as we?d like to get it in relatively quickly so we can move forward on the content side of our plugin. 

For the reverse proxy, would it be easier from a customer standpoint to just include a reverse proxy servlet such as this one? http://sourceforge.net/projects/j2ep/ 
I?m just thinking that setting up and managing a plugin for the HTTP server may be more complex than including one internally that would be transparent to a customer. 

Thanks, 
Chris 



From: Vojtech Szocs < vszocs at redhat.com > 
Date: September 21, 2012 4:37:31 PM EDT 
To: engine-devel < engine-devel at ovirt.org > 
Subject: [Engine-devel] UI Plugins: PoC patch revision 5 is here 


<blockquote>



Hi guys, 

it's been a while but here comes the latest revision of UI Plugins proof-of-concept patch (please find it attached). 

This revision was originally meant to focus solely on server-side components of the plugin infrastructure. However, I ended up implementing all the major concepts and ideas as discussed on engine-devel mailing list, impacting both client-side and server-side parts of the plugin infrastructure. As a result, UI plugin infrastructure should be pretty much complete now, so we can focus on specific plugin API features in upcoming PoC revisions. 

There's a whole bunch of changes and improvements in this revision, so I'll try to cover all the relevant parts step by step. If you have any comments, questions or ideas, please let me know! 

So here we go... (or if you just want to get the patch, find the link at the end of this message) 



0. Added new Engine configuration values 

UI plugin data path is represented by ConfigValues.UIPluginDataPath enum option ("UIPluginDataPath" in vdc_options table), and resolved relative to ConfigValues.DataDir if possible. Following (default) values: 

    * UIPluginDataPath = ui-plugins 
    * DataDir = /usr/share/ovirt-engine 

result in UI plugin data path: /usr/share/ovirt-engine/ui-plugins 

UI plugin config path is represented by ConfigValues.UIPluginConfigPath enum option ("UIPluginConfigPath" in vdc_options table), and resolved relative to ConfigValues.ConfigDir if possible. Following (default) values: 

    * UIPluginConfigPath = ui-plugins 
    * ConfigDir = /etc/ovirt-engine 

result in UI plugin config path: /etc/ovirt-engine/ui-plugins 

1. Processing UI plugin data on the server 

PluginDataManager is the class responsible for reading, validating and caching UI plugin descriptor/configuration data on the server (Engine). It has two main responsibilities: 

    * return a snapshot of currently valid plugin data ( getCurrentData method) 
    * reload plugin data from local file system if necessary ( reloadData method) 

The reloadData method doesn't modify "live" plugin data directly. Instead, it creates a local working copy of current plugin data, updates this copy as it reads/validates plugin descriptor and configuration files, and attempts to update "live" plugin data through conditional reference re-assignment (using java.util.concurrent.atomic.AtomicReference.compareAndSet method). 

In other words, reloadData method makes no attempts with regard to Java lock-based synchronization, in favor of dealing with "live" data through AtomicReference (reference that involves atomic volatile reads and writes): 

    * In the best case, a thread will succeed in updating "live" data ( AtomicReference.compareAndSet == true), which means that "live" data remained unchanged since this thread acquired a reference of current plugin data. 
    * In the worst case, a thread will NOT succeed in updating "live" data ( AtomicReference.compareAndSet == false), which means that "live" data was already changed by another thread since this thread acquired a reference of current plugin data. 

In my opinion, when dealing with external resources like the local file system, this is a good compromise between performance and up-to-date data. While we might not get "completely-up-to-date" data at the given point in time ( reloadData + getCurrentData ), we are guaranteed to get "recently-up-to-date" and consistent data. In other words, the requirement of "completely-up-to-date" data would involve synchronized statements that would hurt performance. In my (very humble) opinion, the benefit of having "completely-up-to-date" data, at the cost of reduced performance, is not really worth it, especially in our case when the user can just hit refresh (F5) to reload WebAdmin and its plugin data. 

Plugin descriptor files are expected to be placed in UI plugin data path, for example: /usr/share/ovirt-engine/ui-plugins/foo.json 

Following descriptor file attributes are implemented and recognized by the plugin infrastructure: 

    * name : A name that uniquely identifies the plugin (required attribute). 
    * url : URL of plugin host page that invokes the plugin code (required attribute). 
    * config : Default configuration object associated with the plugin (optional attribute). 
    * resourcePath : Path to plugin static resources, relative to UI plugin data path (optional attribute). This is used when serving plugin files through Engine PluginResourceServlet (more on this below). 

Plugin configuration files are expected to be placed in UI plugin config path, for example: /etc/engine/ui-plugins/foo-config.json 

Note that plugin configuration files follow the "<descriptorFileName>-config.json" convention. 

Following configuration file attributes are implemented and recognized by the plugin infrastructure: 

    * config : Custom configuration object associated with the plugin (optional attribute). This overrides the default plugin descriptor configuration, if any. 
    * enabled : Indicates whether the plugin should be loaded on WebAdmin startup (optional attribute). Default value is 'true'. 
    * order : Defines the relative order in which the plugin will be loaded on WebAdmin startup (optional attribute). Default value is Integer.MAX_VALUE (lowest order). 

The concept of merging custom configuration ( config attribute in foo-config.json ), if any, on top of default configuration ( config attribute in foo.json ), if any, remains unchanged. This makes the plugin configuration quite flexible - in my opinion, the added complexity of handling/merging such configuration is definitely worth the effort. 

The enabled attribute is straight-forward, allowing users to turn the given plugin off, if necessary. In future, users should still be able to load such plugins through WebAdmin GUI. 

The order attribute controls the order in which plugins are loaded on WebAdmin startup. Since plugin resources are fetched asynchronously by the browser, this is basically a way of imposing some degree of determinism in the "generally-non-deterministic" plugin environment, which is helpful when troubleshooting problems with multiple plugins. This attribute is also helpful due to file listing methods in java.io.File giving no guarantees that files would be listed in any particular order (otherwise we could just go for the "NN-<descriptorFileName>.json" convention, with NN being the order number). 

2. Modified behavior of WebadminDynamicHostingServlet 

WebadminDynamicHostingServlet is the servlet used to serve WebAdmin application host page (HTML page that bootstraps WebAdmin JavaScript code). 

In addition to its former behavior, as part of handling the given request, WebadminDynamicHostingServlet : 

    * reloads descriptor/configuration data from local file system if necessary, and obtains a snapshot of currently valid plugin data ( PluginDataManager.reloadAndGetCurrentData ) 
    * embeds all plugin meta-data, suitable for use in client-side plugin infrastructure, into WebAdmin host page as "pluginDefinitions" JavaScript array ( PluginDefinitions ) 

As a result, reloading UI plugin descriptor/configuration data is as simple as refreshing (F5) WebAdmin application in the browser (no need to restart Engine). 

3. Added servlet for serving plugin static resources 

PluginResourceServlet is the servlet used to serve UI plugin static files (plugin host page, 3rd party JavaScript, etc.) from the local file system. 

For example, requesting URL: 

    * http://<EngineManagerHost>:8700/webadmin/webadmin/plugin/foo/content/start.html 

will send the content of: 

    * /usr/share/ovirt-engine/ui-plugins/<resourcePath>/content/start.html 

to the client. 

As shown in the above example: 

    * /webadmin/webadmin/plugin/ is the servlet root path for PluginResourceServlet 
    * in the extra path beyond the servlet root path ( /foo/content/start.html ): 




        * /foo represents the name of the plugin 
        * /content/start.html represents the path to requested resource, relative to "UIPluginDataPath / <resourcePath>" 

Note that each plugin using PluginResourceServlet to serve its static files must declare non-empty resourcePath attribute in within the plugin descriptor. 

Also note that PluginResourceServlet , unlike WebadminDynamicHostingServlet , does NOT reload descriptor/configuration data from local file system as part of handling the given request. In other words, it's assumed that plugin data has already been (re)loaded when serving WebAdmin application host page, with subsequent requests to PluginResourceServlet reading the current plugin information. 

Until we solve the cross-origin issue in a clean way, PluginResourceServlet should be used to serve all plugin resources from local file system. 

4. Plugin lifecycle improved to deal with misbehaving plugins 

PluginState enum has been modified to deal with plugins that allow uncaught exceptions to escape from plugin event handler functions (e.g. "UiInit"): 

    * removed state INITIALIZED 
    * added state INITIALIZING : The plugin is (currently) being initialized by calling UiInit event handler function. 
    * added state IN_USE : Plugin's UiInit event handler function has completed successfully, we can now call other event handler functions as necessary. The plugin is in use now. 
    * added state FAILED : An uncaught exception escaped while calling an event handler function, which indicates internal error within the plugin code. The plugin is removed from service. 

I've attached a simple state diagram that illustrates different states and transitions between them (green color is initial state, red color is end state). 

Uncaught exceptions in plugin event handler functions will be caught and handled by the plugin infrastructure. This prevents a misbehaving plugin from breaking WebAdmin application, since WebAdmin is the caller (initiator) of the function call. In such case, the plugin will be removed from service. 

Update on cross-origin issue (consequence of same-origin policy) 

In order for the plugin to access WebAdmin plugin API, plugin host page (e.g. start.html ) must be served from URL on same origin as Engine origin. Otherwise, plugin code running in the context of an iframe'd host page will fail to evaluate "parent.pluginApi" expression, with "parent" being top-level (WebAdmin) window, and "pluginApi" being the global plugin API object exposed by WebAdmin. 

This is why PluginResourceServlet , available on Engine origin, should be used to serve all plugin resources from local file system. 

There's only one issue that remains to be solved: cross-origin "plugin vs. remote service" communication, with "remote service" being anything other than Engine (REST API). In future, we'll address this with Apache reverse proxy configuration, so that users can configure Apache server (placed in front of Engine JBoss AS) to put arbitrary (local or remote non-Engine) services on same origin. However, this requires a change in current Apache configuration. Until then, users can manually edit the Engine Apache configuration file ( /etc/httpd/conf.d/ovirt-engine.conf ). 



I've attached some sample plugin files for you to experiment with. Instead of attaching actual patch file (92 kB) to this email, I've submitted the patch to oVirt Gerrit: http://gerrit.ovirt.org/8120 

Let me know what you think! 

Cheers, 
Vojtech 
</blockquote>

<blockquote>


<ui-plugin-sample-files.tar.gz> 
</blockquote>

<blockquote>


<ui-plugin-lifecycle.png> 
</blockquote>

<blockquote>


_______________________________________________ 
Engine-devel mailing list 
Engine-devel at ovirt.org 
http://lists.ovirt.org/mailman/listinfo/engine-devel 
</blockquote>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20121002/1bc55822/attachment.html>

From Christopher.Morrissey at netapp.com  Tue Oct  2 16:15:34 2012
From: Christopher.Morrissey at netapp.com (Morrissey, Christopher)
Date: Tue, 2 Oct 2012 16:15:34 +0000
Subject: [Engine-devel] UI Plugins: PoC patch revision 5 is here
References: <694594112.2447860.1348243049095.JavaMail.root@redhat.com>,
	<994646689.2529178.1348259851832.JavaMail.root@redhat.com>
	<671E0783-1720-4566-A880-F5FB638098CE@netapp.com> 
Message-ID: <D290AD8432118048947689BA3AE8A9B3E47B82@SACEXCMBX04-PRD.hq.netapp.com>

Hi Vojtech,

The patch is great and has cleared up some questions I had about the implementation. I've been able to get the sample plugins working and waded through the code changes, so feel like I have a good understanding of what was delivered. Thanks a lot for putting this all together. I do have a few questions and suggestions for you, though.

Will there eventually be a way to add one or more buttons to the context sensitive buttons and menus throughout the interface? For example, we'd like to allow a button to provision a datastore when a data center, cluster, or host is selected. When the button is clicked, it would open a dialog with an iframe in which we would load our interface to perform the associated action. Some contexts would have several buttons, such as a storage domain (provision, resize, dedupe management, destroy) so it would probably make sense for a drop down menu to be available as well so that the number of buttons above the table doesn't get too cluttered. We'd also like to add these same actions to the menus that popup when a contextual object is right clicked.

If needed we can help work on an implementation for the dialog popup plugin framework as we'd like to get it in relatively quickly so we can move forward on the content side of our plugin.

For the reverse proxy, would it be easier from a customer standpoint to just include a reverse proxy servlet such as this one?  http://sourceforge.net/projects/j2ep/
I'm just thinking that setting up and managing a plugin for the HTTP server may be more complex than including one internally that would be transparent to a customer.

Thanks,
Chris
From: Vojtech Szocs <vszocs at redhat.com<mailto:vszocs at redhat.com>>
Date: September 21, 2012 4:37:31 PM EDT
To: engine-devel <engine-devel at ovirt.org<mailto:engine-devel at ovirt.org>>
Subject: [Engine-devel] UI Plugins: PoC patch revision 5 is here
Hi guys,

it's been a while but here comes the latest revision of UI Plugins proof-of-concept patch (please find it attached).

This revision was originally meant to focus solely on server-side components of the plugin infrastructure. However, I ended up implementing all the major concepts and ideas as discussed on engine-devel mailing list, impacting both client-side and server-side parts of the plugin infrastructure. As a result, UI plugin infrastructure should be pretty much complete now, so we can focus on specific plugin API features in upcoming PoC revisions.

There's a whole bunch of changes and improvements in this revision, so I'll try to cover all the relevant parts step by step. If you have any comments, questions or ideas, please let me know!

So here we go... (or if you just want to get the patch, find the link at the end of this message)
________________________________

0. Added new Engine configuration values

UI plugin data path is represented by ConfigValues.UIPluginDataPath enum option ("UIPluginDataPath" in vdc_options table), and resolved relative to ConfigValues.DataDir if possible. Following (default) values:

  *   UIPluginDataPath = ui-plugins
  *   DataDir = /usr/share/ovirt-engine
result in UI plugin data path: /usr/share/ovirt-engine/ui-plugins

UI plugin config path is represented by ConfigValues.UIPluginConfigPath enum option ("UIPluginConfigPath" in vdc_options table), and resolved relative to ConfigValues.ConfigDir if possible. Following (default) values:

  *   UIPluginConfigPath = ui-plugins
  *   ConfigDir = /etc/ovirt-engine

result in UI plugin config path: /etc/ovirt-engine/ui-plugins

1. Processing UI plugin data on the server

PluginDataManager is the class responsible for reading, validating and caching UI plugin descriptor/configuration data on the server (Engine). It has two main responsibilities:

  *   return a snapshot of currently valid plugin data (getCurrentData method)
  *   reload plugin data from local file system if necessary (reloadData method)

The reloadData method doesn't modify "live" plugin data directly. Instead, it creates a local working copy of current plugin data, updates this copy as it reads/validates plugin descriptor and configuration files, and attempts to update "live" plugin data through conditional reference re-assignment (using java.util.concurrent.atomic.AtomicReference.compareAndSet method).



In other words, reloadData method makes no attempts with regard to Java lock-based synchronization, in favor of dealing with "live" data through AtomicReference (reference that involves atomic volatile reads and writes):

  *   In the best case, a thread will succeed in updating "live" data (AtomicReference.compareAndSet == true), which means that "live" data remained unchanged since this thread acquired a reference of current plugin data.
  *   In the worst case, a thread will NOT succeed in updating "live" data (AtomicReference.compareAndSet == false), which means that "live" data was already changed by another thread since this thread acquired a reference of current plugin data.

In my opinion, when dealing with external resources like the local file system, this is a good compromise between performance and up-to-date data. While we might not get "completely-up-to-date" data at the given point in time (reloadData + getCurrentData), we are guaranteed to get "recently-up-to-date" and consistent data. In other words, the requirement of "completely-up-to-date" data would involve synchronized statements that would hurt performance. In my (very humble) opinion, the benefit of having "completely-up-to-date" data, at the cost of reduced performance, is not really worth it, especially in our case when the user can just hit refresh (F5) to reload WebAdmin and its plugin data.



Plugin descriptor files are expected to be placed in UI plugin data path, for example: /usr/share/ovirt-engine/ui-plugins/foo.json



Following descriptor file attributes are implemented and recognized by the plugin infrastructure:

  *   name: A name that uniquely identifies the plugin (required attribute).
  *   url: URL of plugin host page that invokes the plugin code (required attribute).
  *   config: Default configuration object associated with the plugin (optional attribute).
  *   resourcePath: Path to plugin static resources, relative to UI plugin data path (optional attribute). This is used when serving plugin files through Engine PluginResourceServlet (more on this below).

Plugin configuration files are expected to be placed in UI plugin config path, for example: /etc/engine/ui-plugins/foo-config.json



Note that plugin configuration files follow the "<descriptorFileName>-config.json" convention.



Following configuration file attributes are implemented and recognized by the plugin infrastructure:

  *   config: Custom configuration object associated with the plugin (optional attribute). This overrides the default plugin descriptor configuration, if any.
  *   enabled: Indicates whether the plugin should be loaded on WebAdmin startup (optional attribute). Default value is 'true'.
  *   order: Defines the relative order in which the plugin will be loaded on WebAdmin startup (optional attribute). Default value is Integer.MAX_VALUE (lowest order).

The concept of merging custom configuration (config attribute in foo-config.json), if any, on top of default configuration (config attribute in foo.json), if any, remains unchanged. This makes the plugin configuration quite flexible - in my opinion, the added complexity of handling/merging such configuration is definitely worth the effort.



The enabled attribute is straight-forward, allowing users to turn the given plugin off, if necessary. In future, users should still be able to load such plugins through WebAdmin GUI.



The order attribute controls the order in which plugins are loaded on WebAdmin startup. Since plugin resources are fetched asynchronously by the browser, this is basically a way of imposing some degree of determinism in the "generally-non-deterministic" plugin environment, which is helpful when troubleshooting problems with multiple plugins. This attribute is also helpful due to file listing methods in java.io.File giving no guarantees that files would be listed in any particular order (otherwise we could just go for the "NN-<descriptorFileName>.json" convention, with NN being the order number).

2. Modified behavior of WebadminDynamicHostingServlet

WebadminDynamicHostingServlet is the servlet used to serve WebAdmin application host page (HTML page that bootstraps WebAdmin JavaScript code).

In addition to its former behavior, as part of handling the given request, WebadminDynamicHostingServlet:

  *   reloads descriptor/configuration data from local file system if necessary, and obtains a snapshot of currently valid plugin data (PluginDataManager.reloadAndGetCurrentData)
  *   embeds all plugin meta-data, suitable for use in client-side plugin infrastructure, into WebAdmin host page as "pluginDefinitions" JavaScript array (PluginDefinitions)
As a result, reloading UI plugin descriptor/configuration data is as simple as refreshing (F5) WebAdmin application in the browser (no need to restart Engine).

3. Added servlet for serving plugin static resources

PluginResourceServlet is the servlet used to serve UI plugin static files (plugin host page, 3rd party JavaScript, etc.) from the local file system.

For example, requesting URL:

  *   http://<EngineManagerHost>:8700/webadmin/webadmin/plugin/foo/content/start.html<http://%3cEngineManagerHost%3e:8700/webadmin/webadmin/plugin/foo/content/start.html>

will send the content of:

  *   /usr/share/ovirt-engine/ui-plugins/<resourcePath>/content/start.html

to the client.



As shown in the above example:

  *   /webadmin/webadmin/plugin/ is the servlet root path for PluginResourceServlet
  *   in the extra path beyond the servlet root path (/foo/content/start.html):

     *   /foo represents the name of the plugin
     *   /content/start.html represents the path to requested resource, relative to "UIPluginDataPath / <resourcePath>"
Note that each plugin using PluginResourceServlet to serve its static files must declare non-empty resourcePath attribute in within the plugin descriptor.

Also note that PluginResourceServlet, unlike WebadminDynamicHostingServlet, does NOT reload descriptor/configuration data from local file system as part of handling the given request. In other words, it's assumed that plugin data has already been (re)loaded when serving WebAdmin application host page, with subsequent requests to PluginResourceServlet reading the current plugin information.

Until we solve the cross-origin issue in a clean way, PluginResourceServlet should be used to serve all plugin resources from local file system.

4. Plugin lifecycle improved to deal with misbehaving plugins

PluginState enum has been modified to deal with plugins that allow uncaught exceptions to escape from plugin event handler functions (e.g. "UiInit"):

  *   removed state INITIALIZED
  *   added state INITIALIZING: The plugin is (currently) being initialized by calling UiInit event handler function.
  *   added state IN_USE: Plugin's UiInit event handler function has completed successfully, we can now call other event handler functions as necessary. The plugin is in use now.
  *   added state FAILED: An uncaught exception escaped while calling an event handler function, which indicates internal error within the plugin code. The plugin is removed from service.
I've attached a simple state diagram that illustrates different states and transitions between them (green color is initial state, red color is end state).

Uncaught exceptions in plugin event handler functions will be caught and handled by the plugin infrastructure. This prevents a misbehaving plugin from breaking WebAdmin application, since WebAdmin is the caller (initiator) of the function call. In such case, the plugin will be removed from service.

Update on cross-origin issue (consequence of same-origin policy)

In order for the plugin to access WebAdmin plugin API, plugin host page (e.g. start.html) must be served from URL on same origin as Engine origin. Otherwise, plugin code running in the context of an iframe'd host page will fail to evaluate "parent.pluginApi" expression, with "parent" being top-level (WebAdmin) window, and "pluginApi" being the global plugin API object exposed by WebAdmin.

This is why PluginResourceServlet, available on Engine origin, should be used to serve all plugin resources from local file system.

There's only one issue that remains to be solved: cross-origin "plugin vs. remote service" communication, with "remote service" being anything other than Engine (REST API). In future, we'll address this with Apache reverse proxy configuration, so that users can configure Apache server (placed in front of Engine JBoss AS) to put arbitrary (local or remote non-Engine) services on same origin. However, this requires a change in current Apache configuration. Until then, users can manually edit the Engine Apache configuration file (/etc/httpd/conf.d/ovirt-engine.conf).
________________________________

I've attached some sample plugin files for you to experiment with. Instead of attaching actual patch file (92 kB) to this email, I've submitted the patch to oVirt Gerrit: http://gerrit.ovirt.org/8120

Let me know what you think!

Cheers,
Vojtech
<ui-plugin-sample-files.tar.gz>
<ui-plugin-lifecycle.png>
_______________________________________________
Engine-devel mailing list
Engine-devel at ovirt.org<mailto:Engine-devel at ovirt.org>
http://lists.ovirt.org/mailman/listinfo/engine-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20121002/d28adba9/attachment.html>

From Christopher.Morrissey at netapp.com  Tue Oct  2 19:15:45 2012
From: Christopher.Morrissey at netapp.com (Morrissey, Christopher)
Date: Tue, 2 Oct 2012 19:15:45 +0000
Subject: [Engine-devel] UI Plugins: PoC patch revision 5 is here
In-Reply-To: <343178476.3896355.1349203611681.JavaMail.root@redhat.com>
References: <D290AD8432118048947689BA3AE8A9B3E47B82@SACEXCMBX04-PRD.hq.netapp.com>
	<343178476.3896355.1349203611681.JavaMail.root@redhat.com>
Message-ID: <D290AD8432118048947689BA3AE8A9B3E47C3D@SACEXCMBX04-PRD.hq.netapp.com>

Hi Vojtech,

Thanks for the reply. The plugin framework for adding a custom context sensitive button/menu item and the iframe loading support for the main tab plugin will be welcome additions.

For the custom UI dialog, we?re looking for something that works similar to the tab in that it will show a particular URL in an iFrame in a dialog. Or potentially since it is a dialog, it could just show it in separate window altogether. The dialog would be opened when the context sensitive button or menu item is activated. So it would be nice if the plugin framework would allow a plugged in button definition to define a URL to load in a dialog when it is activated.

I?ll start looking at adding the ability to launch a dialog with context through the plugin API and let you know how that goes in a few days (Maybe sooner if I have questions about it. ;)

Finally, would it be possible to give an estimate on when you think the PoC rev 6 will be available? We?ve got scheduled deliveries internally based on this code and it would be better to make sure everything lines up now.

Thanks!

Chris

From: Vojtech Szocs [mailto:vszocs at redhat.com]
Sent: Tuesday, October 02, 2012 2:47 PM
To: Morrissey, Christopher
Cc: Costea, George; Schoenbrun, Dustin; engine-devel at ovirt.org
Subject: Re: [Engine-devel] UI Plugins: PoC patch revision 5 is here

Hi Chris,

many thanks for your feedback and suggestions :)

Adding context-sensitive button with corresponding menu item sounds good! In fact, this is the proper way how context menu items should be handled, since WebAdmin data grids work with context-sensitive "action buttons" which are reflected within the context menu. I agree that this is a very useful feature to have in plugin API, it should be implemented as part of next major PoC revision.

I have a question though: when the user clicks the custom button or corresponding context menu item, will your plugin handle common dialog UI (everything except actual content) on its own, or do you prefer to have some kind of "dialog UI" API to create the standard-looking dialog frame for you? I like the idea of using iframe to present custom content though :)

As for grouping multiple context-sensitive buttons and corresponding context menu items, this makes sense and we have something like this already implemented in WebAdmin (in Host main tab, Power Management drop-down group button, but this is defined not to appear in context menu though). I think this should be part of "custom context-sensitive button / menu item" plugin API feature.

> If needed we can help work on an implementation for the dialog popup plugin framework as we?d like to get it in relatively quickly so we can move forward on the content side of our plugin.

If I understand correctly, this is about providing "dialog UI" API to create the standard-looking dialog frame + custom content iframe. I'd like to help with this as well,  but you can play with the code and propose a patch on top of PoC rev.5 [http://gerrit.ovirt.org/8120].

> For the reverse proxy, would it be easier from a customer standpoint to just include a reverse proxy servlet such as this one?

Actually, I was under the impression that oVirt Engine (3.1) package (ovirt-engine) takes care of setting up Apache web server, which redirects all traffic to Engine JBoss AS by default (but maybe I am wrong here). However, if this is the case, an efficient way to work around same-origin policy (cross-origin issues) is to configure Apache's reverese proxy module (mod_proxy), as discussed in another thread on engine-devel: http://lists.ovirt.org/pipermail/engine-devel/2012-September/002511.html

This way, you could use Apache to bring Engine and arbitrary (local or remote) web services on same origin. What do you think?

On the other hand, using a special-purpose reverse proxy servlet directly in Engine, not sure if that's a good idea though.. (I'd prefer configuring "front-end" web server, such as Apache, for this purpose)

I'm also sending a couple of updates:

UI Plugins Follow-Up Meeting: scheduled for Tuesday, October 9 at 4pm GMT+1 (I'll send a meeting invitation soon, also planning to re-write oVirt UI Plugins wiki soon after that)

PoC rev.5 patch update: many thanks to Juan and Doron for reviewing the recent patch [http://gerrit.ovirt.org/8120]! I'll update the patch accordingly as revision 5.1

Planned items to be included in PoC revision 6:

  *   adding custom context-sensitive button (either separately or within a button group), along with corresponding context menu item representation
  *   update custom main tab to show the actual content (iframe) from the given URL
  *   adding custom sub tab that shows content from the given URL



More items to consider having in PoC revision 6:

  *   "dialog UI" API to create the standard-looking dialog frame + custom content iframe
  *   Engine REST API exposed through plugin API
  *   integration with Tasks pane to provide visual feedback on custom operations
  *   extending existing dialogs (e.g. Edit Cluster Policy - custom properties)



Let me know what you think.


Regards,
Vojtech

________________________________
From: "Christopher Morrissey" <Christopher.Morrissey at netapp.com>
To: vszocs at redhat.com
Cc: "George Costea" <George.Costea at netapp.com>, "Dustin Schoenbrun" <Dustin.Schoenbrun at netapp.com>, engine-devel at ovirt.org
Sent: Tuesday, October 2, 2012 6:15:34 PM
Subject: RE: [Engine-devel] UI Plugins: PoC patch revision 5 is here
Hi Vojtech,

The patch is great and has cleared up some questions I had about the implementation. I?ve been able to get the sample plugins working and waded through the code changes, so feel like I have a good understanding of what was delivered. Thanks a lot for putting this all together. I do have a few questions and suggestions for you, though.

Will there eventually be a way to add one or more buttons to the context sensitive buttons and menus throughout the interface? For example, we?d like to allow a button to provision a datastore when a data center, cluster, or host is selected. When the button is clicked, it would open a dialog with an iframe in which we would load our interface to perform the associated action. Some contexts would have several buttons, such as a storage domain (provision, resize, dedupe management, destroy) so it would probably make sense for a drop down menu to be available as well so that the number of buttons above the table doesn?t get too cluttered. We?d also like to add these same actions to the menus that popup when a contextual object is right clicked.

If needed we can help work on an implementation for the dialog popup plugin framework as we?d like to get it in relatively quickly so we can move forward on the content side of our plugin.

For the reverse proxy, would it be easier from a customer standpoint to just include a reverse proxy servlet such as this one?  http://sourceforge.net/projects/j2ep/
I?m just thinking that setting up and managing a plugin for the HTTP server may be more complex than including one internally that would be transparent to a customer.

Thanks,
Chris
From: Vojtech Szocs <vszocs at redhat.com<mailto:vszocs at redhat.com>>
Date: September 21, 2012 4:37:31 PM EDT
To: engine-devel <engine-devel at ovirt.org<mailto:engine-devel at ovirt.org>>
Subject: [Engine-devel] UI Plugins: PoC patch revision 5 is here
Hi guys,

it's been a while but here comes the latest revision of UI Plugins proof-of-concept patch (please find it attached).

This revision was originally meant to focus solely on server-side components of the plugin infrastructure. However, I ended up implementing all the major concepts and ideas as discussed on engine-devel mailing list, impacting both client-side and server-side parts of the plugin infrastructure. As a result, UI plugin infrastructure should be pretty much complete now, so we can focus on specific plugin API features in upcoming PoC revisions.

There's a whole bunch of changes and improvements in this revision, so I'll try to cover all the relevant parts step by step. If you have any comments, questions or ideas, please let me know!

So here we go... (or if you just want to get the patch, find the link at the end of this message)
________________________________

0. Added new Engine configuration values

UI plugin data path is represented by ConfigValues.UIPluginDataPath enum option ("UIPluginDataPath" in vdc_options table), and resolved relative to ConfigValues.DataDir if possible. Following (default) values:

  *   UIPluginDataPath = ui-plugins
  *   DataDir = /usr/share/ovirt-engine
result in UI plugin data path: /usr/share/ovirt-engine/ui-plugins

UI plugin config path is represented by ConfigValues.UIPluginConfigPath enum option ("UIPluginConfigPath" in vdc_options table), and resolved relative to ConfigValues.ConfigDir if possible. Following (default) values:

  *   UIPluginConfigPath = ui-plugins
  *   ConfigDir = /etc/ovirt-engine

result in UI plugin config path: /etc/ovirt-engine/ui-plugins

1. Processing UI plugin data on the server

PluginDataManager is the class responsible for reading, validating and caching UI plugin descriptor/configuration data on the server (Engine). It has two main responsibilities:

  *   return a snapshot of currently valid plugin data (getCurrentData method)
  *   reload plugin data from local file system if necessary (reloadData method)

The reloadData method doesn't modify "live" plugin data directly. Instead, it creates a local working copy of current plugin data, updates this copy as it reads/validates plugin descriptor and configuration files, and attempts to update "live" plugin data through conditional reference re-assignment (using java.util.concurrent.atomic.AtomicReference.compareAndSet method).



In other words, reloadData method makes no attempts with regard to Java lock-based synchronization, in favor of dealing with "live" data through AtomicReference (reference that involves atomic volatile reads and writes):

  *   In the best case, a thread will succeed in updating "live" data (AtomicReference.compareAndSet == true), which means that "live" data remained unchanged since this thread acquired a reference of current plugin data.
  *   In the worst case, a thread will NOT succeed in updating "live" data (AtomicReference.compareAndSet == false), which means that "live" data was already changed by another thread since this thread acquired a reference of current plugin data.

In my opinion, when dealing with external resources like the local file system, this is a good compromise between performance and up-to-date data. While we might not get "completely-up-to-date" data at the given point in time (reloadData + getCurrentData), we are guaranteed to get "recently-up-to-date" and consistent data. In other words, the requirement of "completely-up-to-date" data would involve synchronized statements that would hurt performance. In my (very humble) opinion, the benefit of having "completely-up-to-date" data, at the cost of reduced performance, is not really worth it, especially in our case when the user can just hit refresh (F5) to reload WebAdmin and its plugin data.



Plugin descriptor files are expected to be placed in UI plugin data path, for example: /usr/share/ovirt-engine/ui-plugins/foo.json



Following descriptor file attributes are implemented and recognized by the plugin infrastructure:

  *   name: A name that uniquely identifies the plugin (required attribute).
  *   url: URL of plugin host page that invokes the plugin code (required attribute).
  *   config: Default configuration object associated with the plugin (optional attribute).
  *   resourcePath: Path to plugin static resources, relative to UI plugin data path (optional attribute). This is used when serving plugin files through Engine PluginResourceServlet (more on this below).

Plugin configuration files are expected to be placed in UI plugin config path, for example: /etc/engine/ui-plugins/foo-config.json



Note that plugin configuration files follow the "<descriptorFileName>-config.json" convention.



Following configuration file attributes are implemented and recognized by the plugin infrastructure:

  *   config: Custom configuration object associated with the plugin (optional attribute). This overrides the default plugin descriptor configuration, if any.
  *   enabled: Indicates whether the plugin should be loaded on WebAdmin startup (optional attribute). Default value is 'true'.
  *   order: Defines the relative order in which the plugin will be loaded on WebAdmin startup (optional attribute). Default value is Integer.MAX_VALUE (lowest order).

The concept of merging custom configuration (config attribute in foo-config.json), if any, on top of default configuration (config attribute in foo.json), if any, remains unchanged. This makes the plugin configuration quite flexible - in my opinion, the added complexity of handling/merging such configuration is definitely worth the effort.



The enabled attribute is straight-forward, allowing users to turn the given plugin off, if necessary. In future, users should still be able to load such plugins through WebAdmin GUI.



The order attribute controls the order in which plugins are loaded on WebAdmin startup. Since plugin resources are fetched asynchronously by the browser, this is basically a way of imposing some degree of determinism in the "generally-non-deterministic" plugin environment, which is helpful when troubleshooting problems with multiple plugins. This attribute is also helpful due to file listing methods in java.io.File giving no guarantees that files would be listed in any particular order (otherwise we could just go for the "NN-<descriptorFileName>.json" convention, with NN being the order number).

2. Modified behavior of WebadminDynamicHostingServlet

WebadminDynamicHostingServlet is the servlet used to serve WebAdmin application host page (HTML page that bootstraps WebAdmin JavaScript code).

In addition to its former behavior, as part of handling the given request, WebadminDynamicHostingServlet:

  *   reloads descriptor/configuration data from local file system if necessary, and obtains a snapshot of currently valid plugin data (PluginDataManager.reloadAndGetCurrentData)
  *   embeds all plugin meta-data, suitable for use in client-side plugin infrastructure, into WebAdmin host page as "pluginDefinitions" JavaScript array (PluginDefinitions)
As a result, reloading UI plugin descriptor/configuration data is as simple as refreshing (F5) WebAdmin application in the browser (no need to restart Engine).

3. Added servlet for serving plugin static resources

PluginResourceServlet is the servlet used to serve UI plugin static files (plugin host page, 3rd party JavaScript, etc.) from the local file system.

For example, requesting URL:

  *   http://<EngineManagerHost>:8700/webadmin/webadmin/plugin/foo/content/start.html<http://%3cEngineManagerHost%3e:8700/webadmin/webadmin/plugin/foo/content/start.html>

will send the content of:

  *   /usr/share/ovirt-engine/ui-plugins/<resourcePath>/content/start.html

to the client.



As shown in the above example:

  *   /webadmin/webadmin/plugin/ is the servlet root path for PluginResourceServlet
  *   in the extra path beyond the servlet root path (/foo/content/start.html):

     *   /foo represents the name of the plugin
     *   /content/start.html represents the path to requested resource, relative to "UIPluginDataPath / <resourcePath>"
Note that each plugin using PluginResourceServlet to serve its static files must declare non-empty resourcePath attribute in within the plugin descriptor.

Also note that PluginResourceServlet, unlike WebadminDynamicHostingServlet, does NOT reload descriptor/configuration data from local file system as part of handling the given request. In other words, it's assumed that plugin data has already been (re)loaded when serving WebAdmin application host page, with subsequent requests to PluginResourceServlet reading the current plugin information.

Until we solve the cross-origin issue in a clean way, PluginResourceServlet should be used to serve all plugin resources from local file system.

4. Plugin lifecycle improved to deal with misbehaving plugins

PluginState enum has been modified to deal with plugins that allow uncaught exceptions to escape from plugin event handler functions (e.g. "UiInit"):

  *   removed state INITIALIZED
  *   added state INITIALIZING: The plugin is (currently) being initialized by calling UiInit event handler function.
  *   added state IN_USE: Plugin's UiInit event handler function has completed successfully, we can now call other event handler functions as necessary. The plugin is in use now.
  *   added state FAILED: An uncaught exception escaped while calling an event handler function, which indicates internal error within the plugin code. The plugin is removed from service.
I've attached a simple state diagram that illustrates different states and transitions between them (green color is initial state, red color is end state).

Uncaught exceptions in plugin event handler functions will be caught and handled by the plugin infrastructure. This prevents a misbehaving plugin from breaking WebAdmin application, since WebAdmin is the caller (initiator) of the function call. In such case, the plugin will be removed from service.

Update on cross-origin issue (consequence of same-origin policy)

In order for the plugin to access WebAdmin plugin API, plugin host page (e.g. start.html) must be served from URL on same origin as Engine origin. Otherwise, plugin code running in the context of an iframe'd host page will fail to evaluate "parent.pluginApi" expression, with "parent" being top-level (WebAdmin) window, and "pluginApi" being the global plugin API object exposed by WebAdmin.

This is why PluginResourceServlet, available on Engine origin, should be used to serve all plugin resources from local file system.

There's only one issue that remains to be solved: cross-origin "plugin vs. remote service" communication, with "remote service" being anything other than Engine (REST API). In future, we'll address this with Apache reverse proxy configuration, so that users can configure Apache server (placed in front of Engine JBoss AS) to put arbitrary (local or remote non-Engine) services on same origin. However, this requires a change in current Apache configuration. Until then, users can manually edit the Engine Apache configuration file (/etc/httpd/conf.d/ovirt-engine.conf).
________________________________

I've attached some sample plugin files for you to experiment with. Instead of attaching actual patch file (92 kB) to this email, I've submitted the patch to oVirt Gerrit: http://gerrit.ovirt.org/8120

Let me know what you think!

Cheers,
Vojtech
<ui-plugin-sample-files.tar.gz>
<ui-plugin-lifecycle.png>
_______________________________________________
Engine-devel mailing list
Engine-devel at ovirt.org<mailto:Engine-devel at ovirt.org>
http://lists.ovirt.org/mailman/listinfo/engine-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20121002/4522b2a9/attachment.html>

From jhernand at redhat.com  Wed Oct  3 08:24:56 2012
From: jhernand at redhat.com (Juan Hernandez)
Date: Wed, 03 Oct 2012 10:24:56 +0200
Subject: [Engine-devel] UI Plugins: PoC patch revision 5 is here
In-Reply-To: <343178476.3896355.1349203611681.JavaMail.root@redhat.com>
References: <343178476.3896355.1349203611681.JavaMail.root@redhat.com>
Message-ID: <506BF658.6050009@redhat.com>

On 10/02/2012 08:46 PM, Vojtech Szocs wrote:
> Hi Chris, 
> 
> many thanks for your feedback and suggestions :) 
> 
> Adding context-sensitive button with corresponding menu item sounds good! In fact, this is the proper way how context menu items should be handled, since WebAdmin data grids work with context-sensitive "action buttons" which are reflected within the context menu. I agree that this is a very useful feature to have in plugin API, it should be implemented as part of next major PoC revision. 
> 
> I have a question though: when the user clicks the custom button or corresponding context menu item, will your plugin handle common dialog UI (everything except actual content) on its own, or do you prefer to have some kind of "dialog UI" API to create the standard-looking dialog frame for you? I like the idea of using iframe to present custom content though :) 
> 
> As for grouping multiple context-sensitive buttons and corresponding context menu items, this makes sense and we have something like this already implemented in WebAdmin (in Host main tab, Power Management drop-down group button, but this is defined not to appear in context menu though). I think this should be part of "custom context-sensitive button / menu item" plugin API feature. 
> 
>> If needed we can help work on an implementation for the dialog popup plugin framework as we?d like to get it in relatively quickly so we can move forward on the content side of our plugin. 
> 
> If I understand correctly, this is about providing "dialog UI" API to create the standard-looking dialog frame + custom content iframe. I'd like to help with this as well, but you can play with the code and propose a patch on top of PoC rev.5 [http://gerrit.ovirt.org/8120]. 
> 
>> For the reverse proxy, would it be easier from a customer standpoint to just include a reverse proxy servlet such as this one? 
> 
> Actually, I was under the impression that oVirt Engine (3.1) package (ovirt-engine) takes care of setting up Apache web server, which redirects all traffic to Engine JBoss AS by default (but maybe I am wrong here). However, if this is the case, an efficient way to work around same-origin policy (cross-origin issues) is to configure Apache's reverese proxy module (mod_proxy), as discussed in another thread on engine-devel: http://lists.ovirt.org/pipermail/engine-devel/2012-September/002511.html 
> 
> This way, you could use Apache to bring Engine and arbitrary (local or remote) web services on same origin. What do you think? 
> 
> On the other hand, using a special-purpose reverse proxy servlet directly in Engine, not sure if that's a good idea though.. (I'd prefer configuring "front-end" web server, such as Apache, for this purpose) 

Chris, adding the proxy servlet brings a new dependency that can be
difficult to package. The one that you propose in particular is not
included in many distributions, including Fedora.

On the other hand using the web server doesn't bring any additional
dependency, as mod_proxy is already part of almost any installation of
Apache. We already use it by default to redirect requests to the
application server as Vojtech said.

Imagine for example that the engine is running in ovirt.example.com and
that you need to access from your UI plugin a web service running in
netapp.example.com. All what will be needed is dropping a new
netapp-plugin.conf file in the /etc/httpd/conf.d directory with a
content similar to this one:

ProxyPass /myservice http://netapp.example.com/myservice

This can be easily done in the package of your plugin.

There are some things that we need to solve to make this work (currently
we send *all* the requests to the application server), but we want to
solve them anyway.

> I'm also sending a couple of updates: 
> 
> UI Plugins Follow-Up Meeting: scheduled for Tuesday, October 9 at 4pm GMT+1 (I'll send a meeting invitation soon, also planning to re-write oVirt UI Plugins wiki soon after that) 
> 
> PoC rev.5 patch update: many thanks to Juan and Doron for reviewing the recent patch [http://gerrit.ovirt.org/8120]! I'll update the patch accordingly as revision 5.1 
> 
> Planned items to be included in PoC revision 6: 
> 
>     * adding custom context-sensitive button (either separately or within a button group), along with corresponding context menu item representation 
>     * update custom main tab to show the actual content (iframe) from the given URL 
>     * adding custom sub tab that shows content from the given URL 
> 
> 
> 
> More items to consider having in PoC revision 6: 
> 
> 
>     * "dialog UI" API to create the standard-looking dialog frame + custom content iframe 
>     * Engine REST API exposed through plugin API 
>     * integration with Tasks pane to provide visual feedback on custom operations 
>     * extending existing dialogs (e.g. Edit Cluster Policy - custom properties) 
> 
> 
> 
> Let me know what you think. 
> 
> 
> 
> Regards, 
> Vojtech 
> 
> 
> ----- Original Message -----
> 
> From: "Christopher Morrissey" <Christopher.Morrissey at netapp.com> 
> To: vszocs at redhat.com 
> Cc: "George Costea" <George.Costea at netapp.com>, "Dustin Schoenbrun" <Dustin.Schoenbrun at netapp.com>, engine-devel at ovirt.org 
> Sent: Tuesday, October 2, 2012 6:15:34 PM 
> Subject: RE: [Engine-devel] UI Plugins: PoC patch revision 5 is here 
> 
> 
> 
> Hi Vojtech, 
> 
> The patch is great and has cleared up some questions I had about the implementation. I?ve been able to get the sample plugins working and waded through the code changes, so feel like I have a good understanding of what was delivered. Thanks a lot for putting this all together. I do have a few questions and suggestions for you, though. 
> 
> Will there eventually be a way to add one or more buttons to the context sensitive buttons and menus throughout the interface? For example, we?d like to allow a button to provision a datastore when a data center, cluster, or host is selected. When the button is clicked, it would open a dialog with an iframe in which we would load our interface to perform the associated action. Some contexts would have several buttons, such as a storage domain (provision, resize, dedupe management, destroy) so it would probably make sense for a drop down menu to be available as well so that the number of buttons above the table doesn?t get too cluttered. We?d also like to add these same actions to the menus that popup when a contextual object is right clicked. 
> 
> If needed we can help work on an implementation for the dialog popup plugin framework as we?d like to get it in relatively quickly so we can move forward on the content side of our plugin. 
> 
> For the reverse proxy, would it be easier from a customer standpoint to just include a reverse proxy servlet such as this one? http://sourceforge.net/projects/j2ep/ 
> I?m just thinking that setting up and managing a plugin for the HTTP server may be more complex than including one internally that would be transparent to a customer. 
> 
> Thanks, 
> Chris 
> 
> 
> 
> From: Vojtech Szocs < vszocs at redhat.com > 
> Date: September 21, 2012 4:37:31 PM EDT 
> To: engine-devel < engine-devel at ovirt.org > 
> Subject: [Engine-devel] UI Plugins: PoC patch revision 5 is here 
> 
> 
> <blockquote>
> 
> 
> 
> Hi guys, 
> 
> it's been a while but here comes the latest revision of UI Plugins proof-of-concept patch (please find it attached). 
> 
> This revision was originally meant to focus solely on server-side components of the plugin infrastructure. However, I ended up implementing all the major concepts and ideas as discussed on engine-devel mailing list, impacting both client-side and server-side parts of the plugin infrastructure. As a result, UI plugin infrastructure should be pretty much complete now, so we can focus on specific plugin API features in upcoming PoC revisions. 
> 
> There's a whole bunch of changes and improvements in this revision, so I'll try to cover all the relevant parts step by step. If you have any comments, questions or ideas, please let me know! 
> 
> So here we go... (or if you just want to get the patch, find the link at the end of this message) 
> 
> 
> 
> 0. Added new Engine configuration values 
> 
> UI plugin data path is represented by ConfigValues.UIPluginDataPath enum option ("UIPluginDataPath" in vdc_options table), and resolved relative to ConfigValues.DataDir if possible. Following (default) values: 
> 
>     * UIPluginDataPath = ui-plugins 
>     * DataDir = /usr/share/ovirt-engine 
> 
> result in UI plugin data path: /usr/share/ovirt-engine/ui-plugins 
> 
> UI plugin config path is represented by ConfigValues.UIPluginConfigPath enum option ("UIPluginConfigPath" in vdc_options table), and resolved relative to ConfigValues.ConfigDir if possible. Following (default) values: 
> 
>     * UIPluginConfigPath = ui-plugins 
>     * ConfigDir = /etc/ovirt-engine 
> 
> result in UI plugin config path: /etc/ovirt-engine/ui-plugins 
> 
> 1. Processing UI plugin data on the server 
> 
> PluginDataManager is the class responsible for reading, validating and caching UI plugin descriptor/configuration data on the server (Engine). It has two main responsibilities: 
> 
>     * return a snapshot of currently valid plugin data ( getCurrentData method) 
>     * reload plugin data from local file system if necessary ( reloadData method) 
> 
> The reloadData method doesn't modify "live" plugin data directly. Instead, it creates a local working copy of current plugin data, updates this copy as it reads/validates plugin descriptor and configuration files, and attempts to update "live" plugin data through conditional reference re-assignment (using java.util.concurrent.atomic.AtomicReference.compareAndSet method). 
> 
> In other words, reloadData method makes no attempts with regard to Java lock-based synchronization, in favor of dealing with "live" data through AtomicReference (reference that involves atomic volatile reads and writes): 
> 
>     * In the best case, a thread will succeed in updating "live" data ( AtomicReference.compareAndSet == true), which means that "live" data remained unchanged since this thread acquired a reference of current plugin data. 
>     * In the worst case, a thread will NOT succeed in updating "live" data ( AtomicReference.compareAndSet == false), which means that "live" data was already changed by another thread since this thread acquired a reference of current plugin data. 
> 
> In my opinion, when dealing with external resources like the local file system, this is a good compromise between performance and up-to-date data. While we might not get "completely-up-to-date" data at the given point in time ( reloadData + getCurrentData ), we are guaranteed to get "recently-up-to-date" and consistent data. In other words, the requirement of "completely-up-to-date" data would involve synchronized statements that would hurt performance. In my (very humble) opinion, the benefit of having "completely-up-to-date" data, at the cost of reduced performance, is not really worth it, especially in our case when the user can just hit refresh (F5) to reload WebAdmin and its plugin data. 
> 
> Plugin descriptor files are expected to be placed in UI plugin data path, for example: /usr/share/ovirt-engine/ui-plugins/foo.json 
> 
> Following descriptor file attributes are implemented and recognized by the plugin infrastructure: 
> 
>     * name : A name that uniquely identifies the plugin (required attribute). 
>     * url : URL of plugin host page that invokes the plugin code (required attribute). 
>     * config : Default configuration object associated with the plugin (optional attribute). 
>     * resourcePath : Path to plugin static resources, relative to UI plugin data path (optional attribute). This is used when serving plugin files through Engine PluginResourceServlet (more on this below). 
> 
> Plugin configuration files are expected to be placed in UI plugin config path, for example: /etc/engine/ui-plugins/foo-config.json 
> 
> Note that plugin configuration files follow the "<descriptorFileName>-config.json" convention. 
> 
> Following configuration file attributes are implemented and recognized by the plugin infrastructure: 
> 
>     * config : Custom configuration object associated with the plugin (optional attribute). This overrides the default plugin descriptor configuration, if any. 
>     * enabled : Indicates whether the plugin should be loaded on WebAdmin startup (optional attribute). Default value is 'true'. 
>     * order : Defines the relative order in which the plugin will be loaded on WebAdmin startup (optional attribute). Default value is Integer.MAX_VALUE (lowest order). 
> 
> The concept of merging custom configuration ( config attribute in foo-config.json ), if any, on top of default configuration ( config attribute in foo.json ), if any, remains unchanged. This makes the plugin configuration quite flexible - in my opinion, the added complexity of handling/merging such configuration is definitely worth the effort. 
> 
> The enabled attribute is straight-forward, allowing users to turn the given plugin off, if necessary. In future, users should still be able to load such plugins through WebAdmin GUI. 
> 
> The order attribute controls the order in which plugins are loaded on WebAdmin startup. Since plugin resources are fetched asynchronously by the browser, this is basically a way of imposing some degree of determinism in the "generally-non-deterministic" plugin environment, which is helpful when troubleshooting problems with multiple plugins. This attribute is also helpful due to file listing methods in java.io.File giving no guarantees that files would be listed in any particular order (otherwise we could just go for the "NN-<descriptorFileName>.json" convention, with NN being the order number). 
> 
> 2. Modified behavior of WebadminDynamicHostingServlet 
> 
> WebadminDynamicHostingServlet is the servlet used to serve WebAdmin application host page (HTML page that bootstraps WebAdmin JavaScript code). 
> 
> In addition to its former behavior, as part of handling the given request, WebadminDynamicHostingServlet : 
> 
>     * reloads descriptor/configuration data from local file system if necessary, and obtains a snapshot of currently valid plugin data ( PluginDataManager.reloadAndGetCurrentData ) 
>     * embeds all plugin meta-data, suitable for use in client-side plugin infrastructure, into WebAdmin host page as "pluginDefinitions" JavaScript array ( PluginDefinitions ) 
> 
> As a result, reloading UI plugin descriptor/configuration data is as simple as refreshing (F5) WebAdmin application in the browser (no need to restart Engine). 
> 
> 3. Added servlet for serving plugin static resources 
> 
> PluginResourceServlet is the servlet used to serve UI plugin static files (plugin host page, 3rd party JavaScript, etc.) from the local file system. 
> 
> For example, requesting URL: 
> 
>     * http://<EngineManagerHost>:8700/webadmin/webadmin/plugin/foo/content/start.html 
> 
> will send the content of: 
> 
>     * /usr/share/ovirt-engine/ui-plugins/<resourcePath>/content/start.html 
> 
> to the client. 
> 
> As shown in the above example: 
> 
>     * /webadmin/webadmin/plugin/ is the servlet root path for PluginResourceServlet 
>     * in the extra path beyond the servlet root path ( /foo/content/start.html ): 
> 
> 
> 
> 
>         * /foo represents the name of the plugin 
>         * /content/start.html represents the path to requested resource, relative to "UIPluginDataPath / <resourcePath>" 
> 
> Note that each plugin using PluginResourceServlet to serve its static files must declare non-empty resourcePath attribute in within the plugin descriptor. 
> 
> Also note that PluginResourceServlet , unlike WebadminDynamicHostingServlet , does NOT reload descriptor/configuration data from local file system as part of handling the given request. In other words, it's assumed that plugin data has already been (re)loaded when serving WebAdmin application host page, with subsequent requests to PluginResourceServlet reading the current plugin information. 
> 
> Until we solve the cross-origin issue in a clean way, PluginResourceServlet should be used to serve all plugin resources from local file system. 
> 
> 4. Plugin lifecycle improved to deal with misbehaving plugins 
> 
> PluginState enum has been modified to deal with plugins that allow uncaught exceptions to escape from plugin event handler functions (e.g. "UiInit"): 
> 
>     * removed state INITIALIZED 
>     * added state INITIALIZING : The plugin is (currently) being initialized by calling UiInit event handler function. 
>     * added state IN_USE : Plugin's UiInit event handler function has completed successfully, we can now call other event handler functions as necessary. The plugin is in use now. 
>     * added state FAILED : An uncaught exception escaped while calling an event handler function, which indicates internal error within the plugin code. The plugin is removed from service. 
> 
> I've attached a simple state diagram that illustrates different states and transitions between them (green color is initial state, red color is end state). 
> 
> Uncaught exceptions in plugin event handler functions will be caught and handled by the plugin infrastructure. This prevents a misbehaving plugin from breaking WebAdmin application, since WebAdmin is the caller (initiator) of the function call. In such case, the plugin will be removed from service. 
> 
> Update on cross-origin issue (consequence of same-origin policy) 
> 
> In order for the plugin to access WebAdmin plugin API, plugin host page (e.g. start.html ) must be served from URL on same origin as Engine origin. Otherwise, plugin code running in the context of an iframe'd host page will fail to evaluate "parent.pluginApi" expression, with "parent" being top-level (WebAdmin) window, and "pluginApi" being the global plugin API object exposed by WebAdmin. 
> 
> This is why PluginResourceServlet , available on Engine origin, should be used to serve all plugin resources from local file system. 
> 
> There's only one issue that remains to be solved: cross-origin "plugin vs. remote service" communication, with "remote service" being anything other than Engine (REST API). In future, we'll address this with Apache reverse proxy configuration, so that users can configure Apache server (placed in front of Engine JBoss AS) to put arbitrary (local or remote non-Engine) services on same origin. However, this requires a change in current Apache configuration. Until then, users can manually edit the Engine Apache configuration file ( /etc/httpd/conf.d/ovirt-engine.conf ). 
> 
> 
> 
> I've attached some sample plugin files for you to experiment with. Instead of attaching actual patch file (92 kB) to this email, I've submitted the patch to oVirt Gerrit: http://gerrit.ovirt.org/8120 
> 
> Let me know what you think! 
> 
> Cheers, 
> Vojtech 
> </blockquote>
> 
> <blockquote>
> 
> 
> <ui-plugin-sample-files.tar.gz> 
> </blockquote>
> 
> <blockquote>
> 
> 
> <ui-plugin-lifecycle.png> 
> </blockquote>
> 
> <blockquote>
> 
> 
> _______________________________________________ 
> Engine-devel mailing list 
> Engine-devel at ovirt.org 
> http://lists.ovirt.org/mailman/listinfo/engine-devel 
> </blockquote>
> 
> 
> 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


-- 
Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
3?D, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B82657941 - Red Hat S.L.


From vszocs at redhat.com  Wed Oct  3 10:18:28 2012
From: vszocs at redhat.com (Vojtech Szocs)
Date: Wed, 3 Oct 2012 06:18:28 -0400 (EDT)
Subject: [Engine-devel] UI Plugins: PoC patch revision 5 is here
In-Reply-To: <D290AD8432118048947689BA3AE8A9B3E47C3D@SACEXCMBX04-PRD.hq.netapp.com>
Message-ID: <1087101985.4133381.1349259508247.JavaMail.root@redhat.com>

Hey Chris, 

my idea of implementing context-sensitive buttons (menu items) and related dialogs was to de-couple button registration from actual dialog handling, like so: 

    * add custom button to specific data grid as part of UiInit event, providing callback that represents the "button/menu clicked" action, e.g. "pluginApi.addActionButton(title, callback)" 
    * within the above mentioned callback, show the custom dialog using " pluginApi. showDialog(title, contentUrl, buttons?)" [note: this is the "dialog UI API" I meant in my previous email] 

This basically splits your use-case into two distinct API features (addActionButton, showDialog). For example, one button could show a custom dialog, another one could perform other (non-dialog) actions. What do you think? 

> Or potentially since it is a dialog, it could just show it in separate window altogether. 

Good idea for initial implementation! This could be easily added to PoC rev.6. Ultimately, I'd prefer a "dialog UI API", so that custom dialogs will have same "look and feel" as standard ones (can be done later on though). 

> I?ll start looking at adding the ability to launch a dialog with context through the plugin API and let you know how that goes in a few days (Maybe sooner if I have questions about it. ;) 

Great, I think you could start with the above mentioned initial implementation, here are some tips: 

    * add "showDialog(title, contentUrl)" function to plugin API within PluginManager. exposePluginApi () method 
    * use GWT JSNI to delegate the call to PluginUiFunctions, e.g. PluginUiFunctions.showDialog() method 
    * implement showDialog() method using GWT Window.open (), or WebUtils.openUrlInNewWindow() 


(The above mentioned steps are basically the recipe for adding/implementing new plugin API function.) 

> Finally, would it be possible to give an estimate on when you think the PoC rev 6 will be available? We?ve got scheduled deliveries internally based on this code and it would be better to make sure everything lines up now. 

Well, I'm planning to revisit rev.5 according to review comments, and prepare for UI Plugins Follow-Up Meeting (October 9). I will start working on rev.6 patch right after that. 

Finalizing custom (URL-based iframe'd) main tab, plus API for adding same kind of custom sub tab, should be quite easy - couple of days. 
Custom context-sensitive buttons (menu items), should be easy as well, but there is some UiCommon integration necessary - 3-4 days. 

Maybe we can split these two in separate rev.6 releases, what do you think? If you prefer to have both implemented as part of rev.6 patch, my rough estimate is around October 19. 

Regards, 
Vojtech 


----- Original Message -----

From: "Christopher Morrissey" <Christopher.Morrissey at netapp.com> 
To: "Vojtech Szocs" <vszocs at redhat.com> 
Cc: "George Costea" <George.Costea at netapp.com>, "Dustin Schoenbrun" <Dustin.Schoenbrun at netapp.com>, engine-devel at ovirt.org 
Sent: Tuesday, October 2, 2012 9:15:45 PM 
Subject: RE: [Engine-devel] UI Plugins: PoC patch revision 5 is here 



Hi Vojtech, 

Thanks for the reply. The plugin framework for adding a custom context sensitive button/menu item and the iframe loading support for the main tab plugin will be welcome additions. 

For the custom UI dialog, we?re looking for something that works similar to the tab in that it will show a particular URL in an iFrame in a dialog. Or potentially since it is a dialog, it could just show it in separate window altogether. The dialog would be opened when the context sensitive button or menu item is activated. So it would be nice if the plugin framework would allow a plugged in button definition to define a URL to load in a dialog when it is activated. 

I?ll start looking at adding the ability to launch a dialog with context through the plugin API and let you know how that goes in a few days (Maybe sooner if I have questions about it. ;) 

Finally, would it be possible to give an estimate on when you think the PoC rev 6 will be available? We?ve got scheduled deliveries internally based on this code and it would be better to make sure everything lines up now. 

Thanks! 

Chris 



From: Vojtech Szocs [mailto:vszocs at redhat.com] 
Sent: Tuesday, October 02, 2012 2:47 PM 
To: Morrissey, Christopher 
Cc: Costea, George; Schoenbrun, Dustin; engine-devel at ovirt.org 
Subject: Re: [Engine-devel] UI Plugins: PoC patch revision 5 is here 


Hi Chris, 

many thanks for your feedback and suggestions :) 

Adding context-sensitive button with corresponding menu item sounds good! In fact, this is the proper way how context menu items should be handled, since WebAdmin data grids work with context-sensitive "action buttons" which are reflected within the context menu. I agree that this is a very useful feature to have in plugin API, it should be implemented as part of next major PoC revision. 

I have a question though: when the user clicks the custom button or corresponding context menu item, will your plugin handle common dialog UI (everything except actual content) on its own, or do you prefer to have some kind of "dialog UI" API to create the standard-looking dialog frame for you? I like the idea of using iframe to present custom content though :) 

As for grouping multiple context-sensitive buttons and corresponding context menu items, this makes sense and we have something like this already implemented in WebAdmin (in Host main tab, Power Management drop-down group button, but this is defined not to appear in context menu though). I think this should be part of "custom context-sensitive button / menu item" plugin API feature. 

> If needed we can help work on an implementation for the dialog popup plugin framework as we?d like to get it in relatively quickly so we can move forward on the content side of our plugin. 

If I understand correctly, this is about providing "dialog UI" API to create the standard-looking dialog frame + custom content iframe. I'd like to help with this as well, but you can play with the code and propose a patch on top of PoC rev.5 [http://gerrit.ovirt.org/8120]. 

> For the reverse proxy, would it be easier from a customer standpoint to just include a reverse proxy servlet such as this one? 

Actually, I was under the impression that oVirt Engine (3.1) package (ovirt-engine) takes care of setting up Apache web server, which redirects all traffic to Engine JBoss AS by default (but maybe I am wrong here). However, if this is the case, an efficient way to work around same-origin policy (cross-origin issues) is to configure Apache's reverese proxy module (mod_proxy), as discussed in another thread on engine-devel: http://lists.ovirt.org/pipermail/engine-devel/2012-September/002511.html 

This way, you could use Apache to bring Engine and arbitrary (local or remote) web services on same origin. What do you think? 

On the other hand, using a special-purpose reverse proxy servlet directly in Engine, not sure if that's a good idea though.. (I'd prefer configuring "front-end" web server, such as Apache, for this purpose) 

I'm also sending a couple of updates: 

UI Plugins Follow-Up Meeting: scheduled for Tuesday, October 9 at 4pm GMT+1 (I'll send a meeting invitation soon, also planning to re-write oVirt UI Plugins wiki soon after that) 

PoC rev.5 patch update: many thanks to Juan and Doron for reviewing the recent patch [http://gerrit.ovirt.org/8120]! I'll update the patch accordingly as revision 5.1 

Planned items to be included in PoC revision 6: 

    * adding custom context-sensitive button (either separately or within a button group), along with corresponding context menu item representation 
    * update custom main tab to show the actual content (iframe) from the given URL 
    * adding custom sub tab that shows content from the given URL 


More items to consider having in PoC revision 6: 

    * "dialog UI" API to create the standard-looking dialog frame + custom content iframe 
    * Engine REST API exposed through plugin API 
    * integration with Tasks pane to provide visual feedback on custom operations 
    * extending existing dialogs (e.g. Edit Cluster Policy - custom properties) 


Let me know what you think. 

Regards, 
Vojtech 


----- Original Message -----


From: "Christopher Morrissey" <Christopher.Morrissey at netapp.com> 
To: vszocs at redhat.com 
Cc: "George Costea" <George.Costea at netapp.com>, "Dustin Schoenbrun" <Dustin.Schoenbrun at netapp.com>, engine-devel at ovirt.org 
Sent: Tuesday, October 2, 2012 6:15:34 PM 
Subject: RE: [Engine-devel] UI Plugins: PoC patch revision 5 is here 
Hi Vojtech, 

The patch is great and has cleared up some questions I had about the implementation. I?ve been able to get the sample plugins working and waded through the code changes, so feel like I have a good understanding of what was delivered. Thanks a lot for putting this all together. I do have a few questions and suggestions for you, though. 

Will there eventually be a way to add one or more buttons to the context sensitive buttons and menus throughout the interface? For example, we?d like to allow a button to provision a datastore when a data center, cluster, or host is selected. When the button is clicked, it would open a dialog with an iframe in which we would load our interface to perform the associated action. Some contexts would have several buttons, such as a storage domain (provision, resize, dedupe management, destroy) so it would probably make sense for a drop down menu to be available as well so that the number of buttons above the table doesn?t get too cluttered. We?d also like to add these same actions to the menus that popup when a contextual object is right clicked. 

If needed we can help work on an implementation for the dialog popup plugin framework as we?d like to get it in relatively quickly so we can move forward on the content side of our plugin. 

For the reverse proxy, would it be easier from a customer standpoint to just include a reverse proxy servlet such as this one? http://sourceforge.net/projects/j2ep/ 
I?m just thinking that setting up and managing a plugin for the HTTP server may be more complex than including one internally that would be transparent to a customer. 

Thanks, 
Chris 



From: Vojtech Szocs < vszocs at redhat.com > 
Date: September 21, 2012 4:37:31 PM EDT 
To: engine-devel < engine-devel at ovirt.org > 
Subject: [Engine-devel] UI Plugins: PoC patch revision 5 is here 


<blockquote>



Hi guys, 

it's been a while but here comes the latest revision of UI Plugins proof-of-concept patch (please find it attached). 

This revision was originally meant to focus solely on server-side components of the plugin infrastructure. However, I ended up implementing all the major concepts and ideas as discussed on engine-devel mailing list, impacting both client-side and server-side parts of the plugin infrastructure. As a result, UI plugin infrastructure should be pretty much complete now, so we can focus on specific plugin API features in upcoming PoC revisions. 

There's a whole bunch of changes and improvements in this revision, so I'll try to cover all the relevant parts step by step. If you have any comments, questions or ideas, please let me know! 

So here we go... (or if you just want to get the patch, find the link at the end of this message) 



0. Added new Engine configuration values 

UI plugin data path is represented by ConfigValues.UIPluginDataPath enum option ("UIPluginDataPath" in vdc_options table), and resolved relative to ConfigValues.DataDir if possible. Following (default) values: 

    * UIPluginDataPath = ui-plugins 
    * DataDir = /usr/share/ovirt-engine 

result in UI plugin data path: /usr/share/ovirt-engine/ui-plugins 

UI plugin config path is represented by ConfigValues.UIPluginConfigPath enum option ("UIPluginConfigPath" in vdc_options table), and resolved relative to ConfigValues.ConfigDir if possible. Following (default) values: 

    * UIPluginConfigPath = ui-plugins 
    * ConfigDir = /etc/ovirt-engine 

result in UI plugin config path: /etc/ovirt-engine/ui-plugins 

1. Processing UI plugin data on the server 

PluginDataManager is the class responsible for reading, validating and caching UI plugin descriptor/configuration data on the server (Engine). It has two main responsibilities: 

    * return a snapshot of currently valid plugin data ( getCurrentData method) 
    * reload plugin data from local file system if necessary ( reloadData method) 

The reloadData method doesn't modify "live" plugin data directly. Instead, it creates a local working copy of current plugin data, updates this copy as it reads/validates plugin descriptor and configuration files, and attempts to update "live" plugin data through conditional reference re-assignment (using java.util.concurrent.atomic.AtomicReference.compareAndSet method). 

In other words, reloadData method makes no attempts with regard to Java lock-based synchronization, in favor of dealing with "live" data through AtomicReference (reference that involves atomic volatile reads and writes): 

    * In the best case, a thread will succeed in updating "live" data ( AtomicReference.compareAndSet == true), which means that "live" data remained unchanged since this thread acquired a reference of current plugin data. 
    * In the worst case, a thread will NOT succeed in updating "live" data ( AtomicReference.compareAndSet == false), which means that "live" data was already changed by another thread since this thread acquired a reference of current plugin data. 

In my opinion, when dealing with external resources like the local file system, this is a good compromise between performance and up-to-date data. While we might not get "completely-up-to-date" data at the given point in time ( reloadData + getCurrentData ), we are guaranteed to get "recently-up-to-date" and consistent data. In other words, the requirement of "completely-up-to-date" data would involve synchronized statements that would hurt performance. In my (very humble) opinion, the benefit of having "completely-up-to-date" data, at the cost of reduced performance, is not really worth it, especially in our case when the user can just hit refresh (F5) to reload WebAdmin and its plugin data. 

Plugin descriptor files are expected to be placed in UI plugin data path, for example: /usr/share/ovirt-engine/ui-plugins/foo.json 

Following descriptor file attributes are implemented and recognized by the plugin infrastructure: 

    * name : A name that uniquely identifies the plugin (required attribute). 
    * url : URL of plugin host page that invokes the plugin code (required attribute). 
    * config : Default configuration object associated with the plugin (optional attribute). 
    * resourcePath : Path to plugin static resources, relative to UI plugin data path (optional attribute). This is used when serving plugin files through Engine PluginResourceServlet (more on this below). 

Plugin configuration files are expected to be placed in UI plugin config path, for example: /etc/engine/ui-plugins/foo-config.json 

Note that plugin configuration files follow the "<descriptorFileName>-config.json" convention. 

Following configuration file attributes are implemented and recognized by the plugin infrastructure: 

    * config : Custom configuration object associated with the plugin (optional attribute). This overrides the default plugin descriptor configuration, if any. 
    * enabled : Indicates whether the plugin should be loaded on WebAdmin startup (optional attribute). Default value is 'true'. 
    * order : Defines the relative order in which the plugin will be loaded on WebAdmin startup (optional attribute). Default value is Integer.MAX_VALUE (lowest order). 

The concept of merging custom configuration ( config attribute in foo-config.json ), if any, on top of default configuration ( config attribute in foo.json ), if any, remains unchanged. This makes the plugin configuration quite flexible - in my opinion, the added complexity of handling/merging such configuration is definitely worth the effort. 

The enabled attribute is straight-forward, allowing users to turn the given plugin off, if necessary. In future, users should still be able to load such plugins through WebAdmin GUI. 

The order attribute controls the order in which plugins are loaded on WebAdmin startup. Since plugin resources are fetched asynchronously by the browser, this is basically a way of imposing some degree of determinism in the "generally-non-deterministic" plugin environment, which is helpful when troubleshooting problems with multiple plugins. This attribute is also helpful due to file listing methods in java.io.File giving no guarantees that files would be listed in any particular order (otherwise we could just go for the "NN-<descriptorFileName>.json" convention, with NN being the order number). 

2. Modified behavior of WebadminDynamicHostingServlet 

WebadminDynamicHostingServlet is the servlet used to serve WebAdmin application host page (HTML page that bootstraps WebAdmin JavaScript code). 

In addition to its former behavior, as part of handling the given request, WebadminDynamicHostingServlet : 

    * reloads descriptor/configuration data from local file system if necessary, and obtains a snapshot of currently valid plugin data ( PluginDataManager.reloadAndGetCurrentData ) 
    * embeds all plugin meta-data, suitable for use in client-side plugin infrastructure, into WebAdmin host page as "pluginDefinitions" JavaScript array ( PluginDefinitions ) 

As a result, reloading UI plugin descriptor/configuration data is as simple as refreshing (F5) WebAdmin application in the browser (no need to restart Engine). 

3. Added servlet for serving plugin static resources 

PluginResourceServlet is the servlet used to serve UI plugin static files (plugin host page, 3rd party JavaScript, etc.) from the local file system. 

For example, requesting URL: 

    * http://<EngineManagerHost>:8700/webadmin/webadmin/plugin/foo/content/start.html 

will send the content of: 

    * /usr/share/ovirt-engine/ui-plugins/<resourcePath>/content/start.html 

to the client. 

As shown in the above example: 

    * /webadmin/webadmin/plugin/ is the servlet root path for PluginResourceServlet 
    * in the extra path beyond the servlet root path ( /foo/content/start.html ): 




        * /foo represents the name of the plugin 
        * /content/start.html represents the path to requested resource, relative to "UIPluginDataPath / <resourcePath>" 

Note that each plugin using PluginResourceServlet to serve its static files must declare non-empty resourcePath attribute in within the plugin descriptor. 

Also note that PluginResourceServlet , unlike WebadminDynamicHostingServlet , does NOT reload descriptor/configuration data from local file system as part of handling the given request. In other words, it's assumed that plugin data has already been (re)loaded when serving WebAdmin application host page, with subsequent requests to PluginResourceServlet reading the current plugin information. 

Until we solve the cross-origin issue in a clean way, PluginResourceServlet should be used to serve all plugin resources from local file system. 

4. Plugin lifecycle improved to deal with misbehaving plugins 

PluginState enum has been modified to deal with plugins that allow uncaught exceptions to escape from plugin event handler functions (e.g. "UiInit"): 

    * removed state INITIALIZED 
    * added state INITIALIZING : The plugin is (currently) being initialized by calling UiInit event handler function. 
    * added state IN_USE : Plugin's UiInit event handler function has completed successfully, we can now call other event handler functions as necessary. The plugin is in use now. 
    * added state FAILED : An uncaught exception escaped while calling an event handler function, which indicates internal error within the plugin code. The plugin is removed from service. 

I've attached a simple state diagram that illustrates different states and transitions between them (green color is initial state, red color is end state). 

Uncaught exceptions in plugin event handler functions will be caught and handled by the plugin infrastructure. This prevents a misbehaving plugin from breaking WebAdmin application, since WebAdmin is the caller (initiator) of the function call. In such case, the plugin will be removed from service. 

Update on cross-origin issue (consequence of same-origin policy) 

In order for the plugin to access WebAdmin plugin API, plugin host page (e.g. start.html ) must be served from URL on same origin as Engine origin. Otherwise, plugin code running in the context of an iframe'd host page will fail to evaluate "parent.pluginApi" expression, with "parent" being top-level (WebAdmin) window, and "pluginApi" being the global plugin API object exposed by WebAdmin. 

This is why PluginResourceServlet , available on Engine origin, should be used to serve all plugin resources from local file system. 

There's only one issue that remains to be solved: cross-origin "plugin vs. remote service" communication, with "remote service" being anything other than Engine (REST API). In future, we'll address this with Apache reverse proxy configuration, so that users can configure Apache server (placed in front of Engine JBoss AS) to put arbitrary (local or remote non-Engine) services on same origin. However, this requires a change in current Apache configuration. Until then, users can manually edit the Engine Apache configuration file ( /etc/httpd/conf.d/ovirt-engine.conf ). 



I've attached some sample plugin files for you to experiment with. Instead of attaching actual patch file (92 kB) to this email, I've submitted the patch to oVirt Gerrit: http://gerrit.ovirt.org/8120 

Let me know what you think! 

Cheers, 
Vojtech 
</blockquote>

<blockquote>


<ui-plugin-sample-files.tar.gz> 
</blockquote>

<blockquote>


<ui-plugin-lifecycle.png> 
</blockquote>

<blockquote>


_______________________________________________ 
Engine-devel mailing list 
Engine-devel at ovirt.org 
http://lists.ovirt.org/mailman/listinfo/engine-devel 
</blockquote>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20121003/5941416b/attachment.html>

From mpastern at redhat.com  Wed Oct  3 16:13:39 2012
From: mpastern at redhat.com (Michael Pasternak)
Date: Wed, 03 Oct 2012 18:13:39 +0200
Subject: [Engine-devel] allowing user taking vm from vmpool in user-api
Message-ID: <506C6433.6040607@redhat.com>


Apparently we have gap in vmpool for user-api, we need make users being
able allocating vm/s to themselves,

it can be done via new action on vmpool,

URI: /api/vmpools/xxx/allocate|rel=allocate

thoughts?


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From simon at redhat.com  Wed Oct  3 17:16:44 2012
From: simon at redhat.com (Simon Grinberg)
Date: Wed, 3 Oct 2012 13:16:44 -0400 (EDT)
Subject: [Engine-devel] allowing user taking vm from vmpool in user-api
In-Reply-To: <506C6433.6040607@redhat.com>
Message-ID: <886375362.6446497.1349284604307.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Michael Pasternak" <mpastern at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>, "Miki Kenneth" <mkenneth at redhat.com>
> Cc: "Michal Skrivanek" <mskrivan at redhat.com>
> Sent: Wednesday, October 3, 2012 6:13:39 PM
> Subject: [Engine-devel] allowing user taking vm from vmpool in user-api
> 
> 
> Apparently we have gap in vmpool for user-api, we need make users
> being
> able allocating vm/s to themselves,
> 
> it can be done via new action on vmpool,
> 
> URI: /api/vmpools/xxx/allocate|rel=allocate
> 
> thoughts?

What is the response a VM ref?  

> 
> 
> --
> 
> Michael Pasternak
> RedHat, ENG-Virtualization R&D
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From mpastern at redhat.com  Thu Oct  4 09:56:53 2012
From: mpastern at redhat.com (Michael Pasternak)
Date: Thu, 04 Oct 2012 11:56:53 +0200
Subject: [Engine-devel] new ovirt-engine-cli features (form 3.1 till now)
Message-ID: <506D5D65.5090703@redhat.com>

- support utf-8 encoding
- do not log /connect command in history
- disable /history while not  connected
- add username/password prompt/command-line functionality
- history command does not support pipe redirection #854486
- valid UUIDs are treated as syntax error #854391
- Rename /delete command with /remove #855769
- Raise an error if identifier is not specified in /show command #855750
- remove --show-all option from /show command #855749
- rename "create" command with "add" #855773
- change NoCertificatesError message to ask only for ca_file
- implement /filter flag
- do not write to file i/o during script execution
- shell does not exit when using /exit/ command in script


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From mpastern at redhat.com  Thu Oct  4 09:58:02 2012
From: mpastern at redhat.com (Michael Pasternak)
Date: Thu, 04 Oct 2012 11:58:02 +0200
Subject: [Engine-devel] new ovirt-engine-sdk features (form 3.1 till now)
Message-ID: <506D5DAA.4070701@redhat.com>

-  allow persistent_auth via localhost
-  make /filter header global rather than method driven #857018
-  throw error when connecting to ssl site using http protocol
-  raise NoCertificatesError only when no ca_file specified
-  several rebases to include latest engine features

-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From vszocs at redhat.com  Thu Oct  4 10:23:41 2012
From: vszocs at redhat.com (Vojtech Szocs)
Date: Thu, 4 Oct 2012 06:23:41 -0400 (EDT)
Subject: [Engine-devel] oVirt UI Plugins Presentation
Message-ID: <688693014.4538701.1349346221589.JavaMail.root@redhat.com>

The following is a new meeting request:

Subject: oVirt UI Plugins Presentation 
Organizer: "Vojtech Szocs" <vszocs at redhat.com> 

Time: Tuesday, October 9, 2012, 4:00:00 PM - 6:00:00 PM GMT +01:00 Belgrade, Bratislava, Budapest, Ljubljana, Prague
 
Invitees: engine-devel at ovirt.org; iheim at redhat.com; ecohen at redhat.com; George.Costea at netapp.com; Christopher.Morrissey at netapp.com; Dustin.Schoenbrun at netapp.com; Ricky.Hopper at netapp.com; Troy.Mangum at netapp.com; Chris.Frantz at hp.com 


*~*~*~*~*~*~*~*~*~*

Hi guys, 

let me invite you to a presentation on oVirt UI Plugins feature. 

In this session, you will learn about: 

    * high-level overview of UI Plugins feature: main concepts, how it works 
    * current state of plugin infrastructure, including updates from recent revisions (rev.4 and rev.5) 
    * tutorial on writing simple plugin, providing insight on plugin lifecycle from plugin author perspective 
    * few tips for plugin authors on implementing new plugin API features 






Here are the details required for joining the session. 

Intercall dial-in numbers can be found at: 
https://www.intercallonline.com/portlets/scheduling/viewNumbers/listNumbersByCode.do?confCode=7128867405 

Intercall Conference Code ID: 7128867405 # 


Elluminate session: 
https://sas.elluminate.com/m.jnlp?sid=819&password=M.49FFA576F865467B73763A1B6F57CC 




Regards, 
Vojtech 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20121004/93f3898d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: meeting.ics
Type: text/calendar
Size: 6171 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20121004/93f3898d/attachment.ics>

From vszocs at redhat.com  Thu Oct  4 12:30:22 2012
From: vszocs at redhat.com (Vojtech Szocs)
Date: Thu, 4 Oct 2012 08:30:22 -0400 (EDT)
Subject: [Engine-devel] oVirt GUI available in Japanese language
In-Reply-To: <1330728075.4555359.1349351989208.JavaMail.root@redhat.com>
Message-ID: <8692356.4562897.1349353822937.JavaMail.root@redhat.com>

Hello everyone,

oVirt WebAdmin and UserPortal web applications (GUI) now support Japanese language, please refer to [http://gerrit.ovirt.org/8312] for details.

By default, oVirt GUI is compiled for English locale only.


You can customize this by using "gwt.locale" property:

  $ mvn clean install -Pgwt-admin,gwt-user -Dgwt.locale=default,ja

("default" locale maps to English, "ja" locale maps to Japanese)


Alternatively, you can use "all-langs" profile to compile for all supported locales:

  $ mvn clean install -Pgwt-admin,gwt-user,all-langs


Regards,
Vojtech



From shuming at linux.vnet.ibm.com  Mon Oct  8 16:12:20 2012
From: shuming at linux.vnet.ibm.com (Shu Ming)
Date: Tue, 09 Oct 2012 00:12:20 +0800
Subject: [Engine-devel] How to update vds_bootstrap.py file under two
 different directories in engine server?
Message-ID: <5072FB64.5000106@linux.vnet.ibm.com>

Hi,

I got a question about vds_bootstrap.py file in engine. How do I update
the vds_bootstrap.py file after engine and vdsm-bootstrap packages were
updated? I mean the file under directory
"/usr/share/ovirt-engine/engine.ear/components.war/vds/".
It seems vds_bootstrap.py was updated along with the vdsm-bootstrap
package into another directory "/usr/share/vdsm-bootstrap" but not the
directory "/usr/share/ovirt-engine/engine.ear/components.war/vds/".

-- 
---
?? Shu Ming
Open Virtualization Engineerning; CSTL, IBM Corp.
Tel: 86-10-82451626  Tieline: 9051626 E-mail: shuming at cn.ibm.com or shuming at linux.vnet.ibm.com
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District, Beijing 100193, PRC




From ovirt at qip.ru  Tue Oct  9 08:18:54 2012
From: ovirt at qip.ru (ovirt at qip.ru)
Date: Tue, 09 Oct 2012 12:18:54 +0400
Subject: [Engine-devel] jenkins ovirt-engine_create_rpms project
Message-ID: <eaf59ce692a35ad0e06edc23f85e1c83d4626f19@mail.qip.ru>

Hi,

last start of ovirt-engine_create_rpms job was more than one month ago, may be it is possible to start ovirt-engine_create_rpms once a day before publish_ovirt_rpms_nightly ?




From alkaplan at redhat.com  Tue Oct  9 09:34:56 2012
From: alkaplan at redhat.com (Alona Kaplan)
Date: Tue, 9 Oct 2012 05:34:56 -0400 (EDT)
Subject: [Engine-devel] RFE: Netwrok Main Tab
In-Reply-To: <606596814.5345274.1349199404659.JavaMail.root@redhat.com>
Message-ID: <33897873.9742538.1349775296007.JavaMail.root@redhat.com>

The wiki was updated with the final design.
http://wiki.ovirt.org/wiki/Feature/NetworkMainTab

Thanks for the comments,
Alona.

----- Original Message -----
> From: "Simon Grinberg" <simon at redhat.com>
> To: "Alona Kaplan" <alkaplan at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Tuesday, October 2, 2012 7:36:44 PM
> Subject: Re: [Engine-devel] RFE: Netwrok Main Tab
> 
> Trying to sum up some of the suggestions ('coincidently' dropping
> those which I think a bit too much for first implementation :)) and
> add some suggestions of my own
> 
> 1. On the hosts subtab:
>    1.1 Have a radio button that will show either
>        1.1.1 All the hosts that this network is attached to
>        1.1.2 All the hosts where this network attached to the cluster
>        but not to the host (Very important for non-required where
>        the host status does not indicate something is missing)
>    1.2 Have a remove button for 1.1.1, ManageNetworks button for
>    1.1.2. Simple add will not do since you don't know where to add.
> 
> 2. On the vms subtab
>    2.1 Have a radio button that will show either
>        2.1.1 All the vms that this network is attached to
>        2.1.2 All the vms where this network is not attached to
>    2.2 Have a 'remove' button for 2.1.1, Have 'add' button for 2.1.2
>    2.3 Allow multiple selection for both actions of 2.2
>    2.4 Add remove from all button.
>    2.5 I would not bother to show all the nics attached to the VM
>    from the same network, it's too rare. Just make sure there is no
>    exception if this does exist. So the columns should have 'nic' as
>    the first and there should be only one VM per line. If there are
>    more then one nic per VM then just indicate 'multiple'
> 
> 3. Templates subtab - same as VM, drop the expansion of the NICs
> list.
> 
> 4. Clusters subtab
>    Allow assign to multiple clusters - same as the edit in the data
>    center tab (Just use the same dialogue)
> 
> 5. Main: You have enough space then why not add the MTU column?
> 
> 6. Queries for the sub tabs: For each needs the reverse query as well
> (Probably more important when adding new network)
> 
> 
> Oops, I think I mostly added and dropped (almost) nothing :)
> 
> Regards,
> Simon
>  
> 
> ----- Original Message -----
> > From: "Avi Tal" <atal at redhat.com>
> > To: "Yaniv Kaul" <ykaul at redhat.com>
> > Cc: engine-devel at ovirt.org
> > Sent: Monday, September 24, 2012 10:13:52 AM
> > Subject: Re: [Engine-devel] RFE: Netwrok Main Tab
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Yaniv Kaul" <ykaul at redhat.com>
> > > To: "Moti Asayag" <masayag at redhat.com>
> > > Cc: engine-devel at ovirt.org
> > > Sent: Sunday, September 23, 2012 6:16:47 PM
> > > Subject: Re: [Engine-devel] RFE: Netwrok Main Tab
> > > 
> > > On 09/23/2012 06:12 PM, Moti Asayag wrote:
> > > > On 09/23/2012 05:01 PM, Yaniv Kaul wrote:
> > > >> On 09/23/2012 04:55 PM, Alona Kaplan wrote:
> > > >>> ----- Original Message -----
> > > >>>> From: "Avi Tal" <atal at redhat.com>
> > > >>>> To: "Alona Kaplan" <alkaplan at redhat.com>
> > > >>>> Cc: engine-devel at ovirt.org
> > > >>>> Sent: Sunday, September 23, 2012 4:17:26 PM
> > > >>>> Subject: Re: [Engine-devel] RFE: Netwrok Main Tab
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>> ----- Original Message -----
> > > >>>>> From: "Alona Kaplan" <alkaplan at redhat.com>
> > > >>>>> To: "Avi Tal" <atal at redhat.com>
> > > >>>>> Cc: engine-devel at ovirt.org
> > > >>>>> Sent: Sunday, September 23, 2012 1:31:32 PM
> > > >>>>> Subject: Re: [Engine-devel] RFE: Netwrok Main Tab
> > > >>>>>
> > > >>>>> 1. What actions do you suggest to add?
> > > >>>> Add, Edit and remove actions of each component.
> > > >>>>
> > > >>> Host:
> > > >>> Add- What will add action on Networks->Hosts sub tab do?
> > > >>> Choose
> > > >>> an
> > > >>> existing host and attach the network to one of its nics?
> > > >>> How will it work? after choosing the host you will open
> > > >>> setupNetworks
> > > >>> window and just enable dragging of the selected network (in
> > > >>> the
> > > >>> main
> > > >>> tab) to a nic? I think it is too much.
> > > >>>
> > > >>> Edit- same as add.
> > > >>>
> > > >>> Remove- What is the meaning of Remove host in network's
> > > >>> context?
> > > >>> The
> > > >>> network will be detached from the host? I think it is
> > > >>> confusing.
> > > >>>
> > > >>> Vm/Template:
> > > >>> Add: What will it do? You will choose a vm and then add a
> > > >>> vnic
> > > >>> to
> > > >>> the
> > > >>> vm? Where will you see the vnic details?
> > > >>> Edit: Same as add.
> > > >>> Remove: You will remove all the vnics that use the selected
> > > >>> network
> > > >>> from the vm? Or do you mean to add a remove per vnic?
> > > >> For all the above: yes.
> > > >> We can certainly work on the small details, but having a main
> > > >> tab
> > > >> with
> > > >> little to no action whatsoever is kinda disappointing.
> > > > IMO adding 'assign' action in the main tab might be handy in
> > > > order
> > > > to
> > > > assign a single network in a single dialog to several clusters.
> > > >
> > > > However It is not clear to me how Add/Edit for a VM in a
> > > > sub-tab
> > > > should
> > > > look like. The VM should have a list of interfaces (represented
> > > > as
> > > > sub
> > > > collection/tree).
> > > 
> > > I was thinking more of right-click on the network, selecting 'Add
> > > to
> > > VM'
> > > and then selecting single/mutliple VMs from a dialog with all the
> > > VMs
> > > (yes, filtered via search).
> > > Y.
> > > 
> > 
> > +1
> > 
> > > > What will be the meaning of 'Add' in that context? Since the VM
> > > > already
> > > > have a vNIC attached to that network. If adding another once,
> > > > it
> > > > should
> > > > be enabled on the record representing the VM itself which will
> > > > confuse
> > > > the user.
> > > > Same goes for 'Edit' of a VM interface under a context of a
> > > > specific
> > > > network: in the current 'Edit VM Interface' you can change the
> > > > network.
> > > > Should the same dialog be used here as well?
> > > >
> > > > The 'Remove' option is the clearer action on this context.
> > > >
> > > >
> > > >> (example of 'small details' - yes, when clicking remove for a
> > > >> VM/template - it will remove all vNICs that use that network
> > > >> from
> > > >> the
> > > >> VM. A VM with more than one vNIC on the same network is not
> > > >> the
> > > >> common
> > > >> case anyway, and if you want to remove just a single vNIC, go
> > > >> to
> > > >> the
> > > >> VM). I think we can also live with Add/Remove only, and
> > > >> 'defer'
> > > >> the edit
> > > >> actions to the respectable objects (host/vm/template) edit
> > > >> dialog
> > > >> boxes
> > > >> that originates from their own main tab.
> > > >>
> > > >> Y.
> > > >>
> > > >>>>> 2. I don't understand your suggestion. You mean add
> > > >>>>> SetupNetworks
> > > >>>>> to
> > > >>>>> the Networks main tab?
> > > >>>> No.
> > > >>>> Just Thinking of a nice display which will present logical
> > > >>>> network
> > > >>>> and his connected host/vm configuration instead of passing
> > > >>>> through
> > > >>>> dub-tabs
> > > >>>> I should give it a deeper thought.
> > > >>>>
> > > >>>>
> > > >>>>> ----- Original Message -----
> > > >>>>>> From: "Avi Tal" <atal at redhat.com>
> > > >>>>>> To: "Alona Kaplan" <alkaplan at redhat.com>
> > > >>>>>> Cc: engine-devel at ovirt.org
> > > >>>>>> Sent: Thursday, September 20, 2012 6:58:05 PM
> > > >>>>>> Subject: Re: [Engine-devel] RFE: Netwrok Main Tab
> > > >>>>>>
> > > >>>>>> 1. Why not having Actions for Hosts, Vms and Templates ?
> > > >>>>>> I believe we should have those actions instead of making
> > > >>>>>> the
> > > >>>>>> user
> > > >>>>>> browse between 'network -> vms -> network (sub tab)' just
> > > >>>>>> in
> > > >>>>>> order
> > > >>>>>> to update VM's network.
> > > >>>>>>
> > > >>>>>> 2. Why having such a big window which most of the time
> > > >>>>>> will
> > > >>>>>> be
> > > >>>>>> empty?
> > > >>>>>>      How many logical network would be existed in the
> > > >>>>>>      system?
> > > >>>>>>      My suggestion is to go for more graphical window
> > > >>>>>>      which
> > > >>>>>>      will
> > > >>>>>>      present:
> > > >>>>>>      A. logical networks
> > > >>>>>>      B. Multiple networks with the host configurations at
> > > >>>>>>      the
> > > >>>>>>      same
> > > >>>>>>      window: very important because most of the System
> > > >>>>>>      admins
> > > >>>>>>      would
> > > >>>>>>      like to have a bigger picture of the entire network
> > > >>>>>>      configuration
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>> ----- Original Message -----
> > > >>>>>> From: "Alona Kaplan" <alkaplan at redhat.com>
> > > >>>>>> To: engine-devel at ovirt.org
> > > >>>>>> Sent: Thursday, September 20, 2012 1:50:15 PM
> > > >>>>>> Subject: [Engine-devel] RFE: Netwrok Main Tab
> > > >>>>>>
> > > >>>>>> Hi all,
> > > >>>>>>
> > > >>>>>> Please review the wiki and add your comments.
> > > >>>>>>
> > > >>>>>> http://wiki.ovirt.org/wiki/Feature/NetworkMainTab
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>> RFE:
> > > >>>>>> https://bugzilla.redhat.com/858742
> > > >>>>>>
> > > >>>>>> Thanks,
> > > >>>>>> Alona.
> > > >>>>>> _______________________________________________
> > > >>>>>> Engine-devel mailing list
> > > >>>>>> Engine-devel at ovirt.org
> > > >>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > >>>>>>
> > > >>> _______________________________________________
> > > >>> Engine-devel mailing list
> > > >>> Engine-devel at ovirt.org
> > > >>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > >> _______________________________________________
> > > >> Engine-devel mailing list
> > > >> Engine-devel at ovirt.org
> > > >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > 
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > 
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> 


From vszocs at redhat.com  Tue Oct  9 10:39:28 2012
From: vszocs at redhat.com (Vojtech Szocs)
Date: Tue, 9 Oct 2012 06:39:28 -0400 (EDT)
Subject: [Engine-devel] oVirt UI Plugins Presentation: PDF slides
In-Reply-To: <1533869568.6212795.1349779076195.JavaMail.root@redhat.com>
Message-ID: <412710972.6212909.1349779168314.JavaMail.root@redhat.com>

Hi guys,

please find the slides for today's UI Plugins presentation attached to this email.

Regards,
Vojtech
-------------- next part --------------
A non-text attachment was scrubbed...
Name: UI-Plugins-Feature'n'Implementation-Overview.pdf
Type: application/pdf
Size: 300621 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20121009/7ec61400/attachment.pdf>

From ykaul at redhat.com  Tue Oct  9 15:01:39 2012
From: ykaul at redhat.com (Yaniv Kaul)
Date: Tue, 09 Oct 2012 17:01:39 +0200
Subject: [Engine-devel] RFE: Netwrok Main Tab
In-Reply-To: <33897873.9742538.1349775296007.JavaMail.root@redhat.com>
References: <33897873.9742538.1349775296007.JavaMail.root@redhat.com>
Message-ID: <50743C53.8070208@redhat.com>

On 10/09/2012 11:34 AM, Alona Kaplan wrote:
> The wiki was updated with the final design.
> http://wiki.ovirt.org/wiki/Feature/NetworkMainTab
>
> Thanks for the comments,
> Alona.

Is the general sub-tab providing any information not available in the 
grid already?
If not, lets drop it.
And while it's also consistent to show the clusters as the second (or 
now, after the above suggestion first) sub-tab, it's not an interesting 
tab. I suggest the default when clicking on a network is to show the VMs 
tab (so while the order of the tabs is not changed, the default shown is).
Y.


>
> ----- Original Message -----
>> From: "Simon Grinberg" <simon at redhat.com>
>> To: "Alona Kaplan" <alkaplan at redhat.com>
>> Cc: engine-devel at ovirt.org
>> Sent: Tuesday, October 2, 2012 7:36:44 PM
>> Subject: Re: [Engine-devel] RFE: Netwrok Main Tab
>>
>> Trying to sum up some of the suggestions ('coincidently' dropping
>> those which I think a bit too much for first implementation :)) and
>> add some suggestions of my own
>>
>> 1. On the hosts subtab:
>>     1.1 Have a radio button that will show either
>>         1.1.1 All the hosts that this network is attached to
>>         1.1.2 All the hosts where this network attached to the cluster
>>         but not to the host (Very important for non-required where
>>         the host status does not indicate something is missing)
>>     1.2 Have a remove button for 1.1.1, ManageNetworks button for
>>     1.1.2. Simple add will not do since you don't know where to add.
>>
>> 2. On the vms subtab
>>     2.1 Have a radio button that will show either
>>         2.1.1 All the vms that this network is attached to
>>         2.1.2 All the vms where this network is not attached to
>>     2.2 Have a 'remove' button for 2.1.1, Have 'add' button for 2.1.2
>>     2.3 Allow multiple selection for both actions of 2.2
>>     2.4 Add remove from all button.
>>     2.5 I would not bother to show all the nics attached to the VM
>>     from the same network, it's too rare. Just make sure there is no
>>     exception if this does exist. So the columns should have 'nic' as
>>     the first and there should be only one VM per line. If there are
>>     more then one nic per VM then just indicate 'multiple'
>>
>> 3. Templates subtab - same as VM, drop the expansion of the NICs
>> list.
>>
>> 4. Clusters subtab
>>     Allow assign to multiple clusters - same as the edit in the data
>>     center tab (Just use the same dialogue)
>>
>> 5. Main: You have enough space then why not add the MTU column?
>>
>> 6. Queries for the sub tabs: For each needs the reverse query as well
>> (Probably more important when adding new network)
>>
>>
>> Oops, I think I mostly added and dropped (almost) nothing :)
>>
>> Regards,
>> Simon
>>   
>>
>> ----- Original Message -----
>>> From: "Avi Tal" <atal at redhat.com>
>>> To: "Yaniv Kaul" <ykaul at redhat.com>
>>> Cc: engine-devel at ovirt.org
>>> Sent: Monday, September 24, 2012 10:13:52 AM
>>> Subject: Re: [Engine-devel] RFE: Netwrok Main Tab
>>>
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Yaniv Kaul" <ykaul at redhat.com>
>>>> To: "Moti Asayag" <masayag at redhat.com>
>>>> Cc: engine-devel at ovirt.org
>>>> Sent: Sunday, September 23, 2012 6:16:47 PM
>>>> Subject: Re: [Engine-devel] RFE: Netwrok Main Tab
>>>>
>>>> On 09/23/2012 06:12 PM, Moti Asayag wrote:
>>>>> On 09/23/2012 05:01 PM, Yaniv Kaul wrote:
>>>>>> On 09/23/2012 04:55 PM, Alona Kaplan wrote:
>>>>>>> ----- Original Message -----
>>>>>>>> From: "Avi Tal" <atal at redhat.com>
>>>>>>>> To: "Alona Kaplan" <alkaplan at redhat.com>
>>>>>>>> Cc: engine-devel at ovirt.org
>>>>>>>> Sent: Sunday, September 23, 2012 4:17:26 PM
>>>>>>>> Subject: Re: [Engine-devel] RFE: Netwrok Main Tab
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ----- Original Message -----
>>>>>>>>> From: "Alona Kaplan" <alkaplan at redhat.com>
>>>>>>>>> To: "Avi Tal" <atal at redhat.com>
>>>>>>>>> Cc: engine-devel at ovirt.org
>>>>>>>>> Sent: Sunday, September 23, 2012 1:31:32 PM
>>>>>>>>> Subject: Re: [Engine-devel] RFE: Netwrok Main Tab
>>>>>>>>>
>>>>>>>>> 1. What actions do you suggest to add?
>>>>>>>> Add, Edit and remove actions of each component.
>>>>>>>>
>>>>>>> Host:
>>>>>>> Add- What will add action on Networks->Hosts sub tab do?
>>>>>>> Choose
>>>>>>> an
>>>>>>> existing host and attach the network to one of its nics?
>>>>>>> How will it work? after choosing the host you will open
>>>>>>> setupNetworks
>>>>>>> window and just enable dragging of the selected network (in
>>>>>>> the
>>>>>>> main
>>>>>>> tab) to a nic? I think it is too much.
>>>>>>>
>>>>>>> Edit- same as add.
>>>>>>>
>>>>>>> Remove- What is the meaning of Remove host in network's
>>>>>>> context?
>>>>>>> The
>>>>>>> network will be detached from the host? I think it is
>>>>>>> confusing.
>>>>>>>
>>>>>>> Vm/Template:
>>>>>>> Add: What will it do? You will choose a vm and then add a
>>>>>>> vnic
>>>>>>> to
>>>>>>> the
>>>>>>> vm? Where will you see the vnic details?
>>>>>>> Edit: Same as add.
>>>>>>> Remove: You will remove all the vnics that use the selected
>>>>>>> network
>>>>>>> from the vm? Or do you mean to add a remove per vnic?
>>>>>> For all the above: yes.
>>>>>> We can certainly work on the small details, but having a main
>>>>>> tab
>>>>>> with
>>>>>> little to no action whatsoever is kinda disappointing.
>>>>> IMO adding 'assign' action in the main tab might be handy in
>>>>> order
>>>>> to
>>>>> assign a single network in a single dialog to several clusters.
>>>>>
>>>>> However It is not clear to me how Add/Edit for a VM in a
>>>>> sub-tab
>>>>> should
>>>>> look like. The VM should have a list of interfaces (represented
>>>>> as
>>>>> sub
>>>>> collection/tree).
>>>> I was thinking more of right-click on the network, selecting 'Add
>>>> to
>>>> VM'
>>>> and then selecting single/mutliple VMs from a dialog with all the
>>>> VMs
>>>> (yes, filtered via search).
>>>> Y.
>>>>
>>> +1
>>>
>>>>> What will be the meaning of 'Add' in that context? Since the VM
>>>>> already
>>>>> have a vNIC attached to that network. If adding another once,
>>>>> it
>>>>> should
>>>>> be enabled on the record representing the VM itself which will
>>>>> confuse
>>>>> the user.
>>>>> Same goes for 'Edit' of a VM interface under a context of a
>>>>> specific
>>>>> network: in the current 'Edit VM Interface' you can change the
>>>>> network.
>>>>> Should the same dialog be used here as well?
>>>>>
>>>>> The 'Remove' option is the clearer action on this context.
>>>>>
>>>>>
>>>>>> (example of 'small details' - yes, when clicking remove for a
>>>>>> VM/template - it will remove all vNICs that use that network
>>>>>> from
>>>>>> the
>>>>>> VM. A VM with more than one vNIC on the same network is not
>>>>>> the
>>>>>> common
>>>>>> case anyway, and if you want to remove just a single vNIC, go
>>>>>> to
>>>>>> the
>>>>>> VM). I think we can also live with Add/Remove only, and
>>>>>> 'defer'
>>>>>> the edit
>>>>>> actions to the respectable objects (host/vm/template) edit
>>>>>> dialog
>>>>>> boxes
>>>>>> that originates from their own main tab.
>>>>>>
>>>>>> Y.
>>>>>>
>>>>>>>>> 2. I don't understand your suggestion. You mean add
>>>>>>>>> SetupNetworks
>>>>>>>>> to
>>>>>>>>> the Networks main tab?
>>>>>>>> No.
>>>>>>>> Just Thinking of a nice display which will present logical
>>>>>>>> network
>>>>>>>> and his connected host/vm configuration instead of passing
>>>>>>>> through
>>>>>>>> dub-tabs
>>>>>>>> I should give it a deeper thought.
>>>>>>>>
>>>>>>>>
>>>>>>>>> ----- Original Message -----
>>>>>>>>>> From: "Avi Tal" <atal at redhat.com>
>>>>>>>>>> To: "Alona Kaplan" <alkaplan at redhat.com>
>>>>>>>>>> Cc: engine-devel at ovirt.org
>>>>>>>>>> Sent: Thursday, September 20, 2012 6:58:05 PM
>>>>>>>>>> Subject: Re: [Engine-devel] RFE: Netwrok Main Tab
>>>>>>>>>>
>>>>>>>>>> 1. Why not having Actions for Hosts, Vms and Templates ?
>>>>>>>>>> I believe we should have those actions instead of making
>>>>>>>>>> the
>>>>>>>>>> user
>>>>>>>>>> browse between 'network -> vms -> network (sub tab)' just
>>>>>>>>>> in
>>>>>>>>>> order
>>>>>>>>>> to update VM's network.
>>>>>>>>>>
>>>>>>>>>> 2. Why having such a big window which most of the time
>>>>>>>>>> will
>>>>>>>>>> be
>>>>>>>>>> empty?
>>>>>>>>>>       How many logical network would be existed in the
>>>>>>>>>>       system?
>>>>>>>>>>       My suggestion is to go for more graphical window
>>>>>>>>>>       which
>>>>>>>>>>       will
>>>>>>>>>>       present:
>>>>>>>>>>       A. logical networks
>>>>>>>>>>       B. Multiple networks with the host configurations at
>>>>>>>>>>       the
>>>>>>>>>>       same
>>>>>>>>>>       window: very important because most of the System
>>>>>>>>>>       admins
>>>>>>>>>>       would
>>>>>>>>>>       like to have a bigger picture of the entire network
>>>>>>>>>>       configuration
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ----- Original Message -----
>>>>>>>>>> From: "Alona Kaplan" <alkaplan at redhat.com>
>>>>>>>>>> To: engine-devel at ovirt.org
>>>>>>>>>> Sent: Thursday, September 20, 2012 1:50:15 PM
>>>>>>>>>> Subject: [Engine-devel] RFE: Netwrok Main Tab
>>>>>>>>>>
>>>>>>>>>> Hi all,
>>>>>>>>>>
>>>>>>>>>> Please review the wiki and add your comments.
>>>>>>>>>>
>>>>>>>>>> http://wiki.ovirt.org/wiki/Feature/NetworkMainTab
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> RFE:
>>>>>>>>>> https://bugzilla.redhat.com/858742
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Alona.
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Engine-devel mailing list
>>>>>>>>>> Engine-devel at ovirt.org
>>>>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Engine-devel mailing list
>>>>>>> Engine-devel at ovirt.org
>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>> _______________________________________________
>>>>>> Engine-devel mailing list
>>>>>> Engine-devel at ovirt.org
>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>> _______________________________________________
>>>> Engine-devel mailing list
>>>> Engine-devel at ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>
>>> _______________________________________________
>>> Engine-devel mailing list
>>> Engine-devel at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>



From rnori at redhat.com  Tue Oct  9 16:40:56 2012
From: rnori at redhat.com (Ravi Nori)
Date: Tue, 09 Oct 2012 12:40:56 -0400
Subject: [Engine-devel] "wipe after delete" Matching defaults from GUI to
	Backend
Message-ID: <50745398.5080803@redhat.com>

I am working on the bug where the defaults values in the GUI for disk 
actions don't correspond to the default values in the API/Backend. For 
example the "wipe after delete" flag defaults to true in the GUI but 
false in the backend code. Default values are not sent from the frontend 
to the backend. Please refer to the bugzilla link

https://bugzilla.redhat.com/show_bug.cgi?id=845466

After discussing with Michael as to how to approach fixing this, we 
think the best way to do it would be to fix it in the Backend class 
businessentities.Disk by replacing primitives with reference types and 
forcing business logic in the class to set the default values to match 
the default values in the client.

I would appreciate some feedback on this and also on what the default 
values are for Disk operations on the GUI.

Thanks

Ravi


From agl at us.ibm.com  Tue Oct  9 18:06:02 2012
From: agl at us.ibm.com (Adam Litke)
Date: Tue, 9 Oct 2012 13:06:02 -0500
Subject: [Engine-devel] Mom Balloon policy issue
In-Reply-To: <1394818892.10205231.1349802750272.JavaMail.root@redhat.com>
References: <1939738834.10171140.1349800230114.JavaMail.root@redhat.com>
	<1394818892.10205231.1349802750272.JavaMail.root@redhat.com>
Message-ID: <20121009180602.GH25171@aglitke>

Thanks for writing this.  Some thoughts inline, below.  Also, cc'ing some lists
in case other folks want to participate in the discussion.

On Tue, Oct 09, 2012 at 01:12:30PM -0400, Noam Slomianko wrote:
> Greetings,
> 
> I've fiddled around with ballooning and wanted to raise a question for debate.
> 
> Currently as long as the host is under memory pressure, MOM will try and reclaim back memory from all guests with more free memory then a given threshold.
> 
> Main issue: Guest allocated memory is not the same as the resident (physical) memory used by qemu.
> This means that when memory is reclaimed back (the balloon is inflated) we might not get as much memory as planed back (or non at all).
> 
>  *Example1 no memory is reclaimed back:
>     name | allocated memory | used by the vm | resident memory used in the host by qemu
>     Vm1  |       4G         |       4G,      |                4G
>     Vm2  |       4G         |       1G       |                1G
>  - MOM will inflate the balloon in vm2 (as vm has no free memory) and will gain no memory

One thing to keep in mind is that VMs having less host RSS than their memory
allocation is a temporary condition.  All VMs will eventually consume their full
allocation if allowed to run.  I'd be curious to know how long this process
takes in general.

We might be able to handle this case by refusing to inflate the balloon if:
    (VM free memory - planned balloon inflation) > host RSS


>  *Example1 memory is reclaimed partially:
>     name | allocated memory | used by the vm | resident memory used in the host by qemu
>     Vm1  |       4G         |       4G,      |                4G
>     Vm2  |       4G         |       1G       |                1G
>     Vm3  |       4G         |       1G       |                4G
>  - MOM will inflate the balloon in vm2 and vm3 slowly gaining only from vm3

The above rule extension may help here too.

> this behaviour might in the cause us to:
>  * spend time reclaiming memory from many guests when we can reclaim only from a subgroup
>  * be under the impression that we have more potential memory to reclaim when we do
>  * bring inactive VMs dangerously low as they are constantly reclaimed (I've had guests crashing from kernel out of memory)
> 
> 
> To address this I suggest that we collect guest memory stats from libvirt as well, so we have the option to use them in our calculations.
> This can be achieved with the command "virsh dommemstat <domain>" which returns
>     actual 3915372 (allocated)
>     rss 2141580 (resident memory used by qemu)

I would suggest adding these two fields to the VmStats that are collected by
vdsm.  Then, to try it out, add the fields to the GuestMemory Collector.  (Note:
MOM does have a collector that gathers RSS for VMs.  It's called GuestQemuProc).
You can then extend the Balloon policy to add a snippet to check if the proposed
balloon adjustment should be carried out.  You could add the logic to the
change_big_enough function.

> additional topic:
>  * should we include per guest config (for example a hard minimum memory cap, this vm cannot run effectively with less then 1G memory)

Yes.  This is probably something we want to do.  There is a whole topic around
VM tagging that we should consider.  In the future we will want to be able to do
many different things in policy based on a VMs tag.  For example, some VMs may
be completely exempt from ballooning.  Others may have a minimum limit.

I want to avoid passing in the raw guest configuration because MOM needs to work
with direct libvirt vms and with ovirt/vdsm vms.  Therefore, we want to think
carefully about the abstractions we use when presenting VM properties to MOM.

-- 
Adam Litke <agl at us.ibm.com>
IBM Linux Technology Center



From danken at redhat.com  Tue Oct  9 21:53:40 2012
From: danken at redhat.com (Dan Kenigsberg)
Date: Tue, 9 Oct 2012 23:53:40 +0200
Subject: [Engine-devel] RFE: Netwrok Main Tab
In-Reply-To: <33897873.9742538.1349775296007.JavaMail.root@redhat.com>
References: <606596814.5345274.1349199404659.JavaMail.root@redhat.com>
	<33897873.9742538.1349775296007.JavaMail.root@redhat.com>
Message-ID: <20121009215340.GA1844@redhat.com>

On Tue, Oct 09, 2012 at 05:34:56AM -0400, Alona Kaplan wrote:
> The wiki was updated with the final design.
> http://wiki.ovirt.org/wiki/Feature/NetworkMainTab
> 
> Thanks for the comments,

One other comment for consideration: it may be interesting to show in
the VM sub-tab the current bandwidth eaten by each VM. For exapmle, if a
network is congensted, such a column would show the cultprit VM quicker.


From derez at redhat.com  Tue Oct  9 23:17:05 2012
From: derez at redhat.com (Daniel Erez)
Date: Tue, 9 Oct 2012 19:17:05 -0400 (EDT)
Subject: [Engine-devel] "wipe after delete" Matching defaults from GUI
 to	Backend
In-Reply-To: <50745398.5080803@redhat.com>
Message-ID: <1486797178.8472794.1349824625385.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Ravi Nori" <rnori at redhat.com>
> To: engine-devel at ovirt.org
> Sent: Tuesday, October 9, 2012 6:40:56 PM
> Subject: [Engine-devel] "wipe after delete" Matching defaults from GUI to	Backend
> 
> I am working on the bug where the defaults values in the GUI for disk
> actions don't correspond to the default values in the API/Backend.
> For
> example the "wipe after delete" flag defaults to true in the GUI but
> false in the backend code. Default values are not sent from the
> frontend
> to the backend. Please refer to the bugzilla link
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=845466
> 
> After discussing with Michael as to how to approach fixing this, we
> think the best way to do it would be to fix it in the Backend class
> businessentities.Disk by replacing primitives with reference types
> and
> forcing business logic in the class to set the default values to
> match
> the default values in the client.
> 
> I would appreciate some feedback on this and also on what the default
> values are for Disk operations on the GUI.

GUI behavior is as follows:
For File storage domains - WipeAfterDelete check-box is unchangeable and unchecked (false).
For Block storage domains - WipeAfterDelete check-box is changeable and 
the default value is according to 'SANWipeAfterDelete' configuration value.

I think you should simply utilize the same configuration value in
REST or backend when creating a new disk. 

> 
> Thanks
> 
> Ravi
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From alkaplan at redhat.com  Wed Oct 10 08:39:50 2012
From: alkaplan at redhat.com (Alona Kaplan)
Date: Wed, 10 Oct 2012 04:39:50 -0400 (EDT)
Subject: [Engine-devel] RFE: Netwrok Main Tab
In-Reply-To: <50743C53.8070208@redhat.com>
Message-ID: <662323620.10689197.1349858390348.JavaMail.root@redhat.com>

I agree.

Simon, what do you think?

----- Original Message -----
> From: "Yaniv Kaul" <ykaul at redhat.com>
> To: "Alona Kaplan" <alkaplan at redhat.com>
> Cc: engine-devel at ovirt.org, "Muli Salem" <msalem at redhat.com>, "Moti Asayag" <masayag at redhat.com>, "Avi Tal"
> <atal at redhat.com>, "Simon Grinberg" <sgrinber at redhat.com>
> Sent: Tuesday, October 9, 2012 5:01:39 PM
> Subject: Re: [Engine-devel] RFE: Netwrok Main Tab
> 
> On 10/09/2012 11:34 AM, Alona Kaplan wrote:
> > The wiki was updated with the final design.
> > http://wiki.ovirt.org/wiki/Feature/NetworkMainTab
> >
> > Thanks for the comments,
> > Alona.
> 
> Is the general sub-tab providing any information not available in the
> grid already?
> If not, lets drop it.
> And while it's also consistent to show the clusters as the second (or
> now, after the above suggestion first) sub-tab, it's not an
> interesting
> tab. I suggest the default when clicking on a network is to show the
> VMs
> tab (so while the order of the tabs is not changed, the default shown
> is).
> Y.
> 
> 
> >
> > ----- Original Message -----
> >> From: "Simon Grinberg" <simon at redhat.com>
> >> To: "Alona Kaplan" <alkaplan at redhat.com>
> >> Cc: engine-devel at ovirt.org
> >> Sent: Tuesday, October 2, 2012 7:36:44 PM
> >> Subject: Re: [Engine-devel] RFE: Netwrok Main Tab
> >>
> >> Trying to sum up some of the suggestions ('coincidently' dropping
> >> those which I think a bit too much for first implementation :))
> >> and
> >> add some suggestions of my own
> >>
> >> 1. On the hosts subtab:
> >>     1.1 Have a radio button that will show either
> >>         1.1.1 All the hosts that this network is attached to
> >>         1.1.2 All the hosts where this network attached to the
> >>         cluster
> >>         but not to the host (Very important for non-required where
> >>         the host status does not indicate something is missing)
> >>     1.2 Have a remove button for 1.1.1, ManageNetworks button for
> >>     1.1.2. Simple add will not do since you don't know where to
> >>     add.
> >>
> >> 2. On the vms subtab
> >>     2.1 Have a radio button that will show either
> >>         2.1.1 All the vms that this network is attached to
> >>         2.1.2 All the vms where this network is not attached to
> >>     2.2 Have a 'remove' button for 2.1.1, Have 'add' button for
> >>     2.1.2
> >>     2.3 Allow multiple selection for both actions of 2.2
> >>     2.4 Add remove from all button.
> >>     2.5 I would not bother to show all the nics attached to the VM
> >>     from the same network, it's too rare. Just make sure there is
> >>     no
> >>     exception if this does exist. So the columns should have 'nic'
> >>     as
> >>     the first and there should be only one VM per line. If there
> >>     are
> >>     more then one nic per VM then just indicate 'multiple'
> >>
> >> 3. Templates subtab - same as VM, drop the expansion of the NICs
> >> list.
> >>
> >> 4. Clusters subtab
> >>     Allow assign to multiple clusters - same as the edit in the
> >>     data
> >>     center tab (Just use the same dialogue)
> >>
> >> 5. Main: You have enough space then why not add the MTU column?
> >>
> >> 6. Queries for the sub tabs: For each needs the reverse query as
> >> well
> >> (Probably more important when adding new network)
> >>
> >>
> >> Oops, I think I mostly added and dropped (almost) nothing :)
> >>
> >> Regards,
> >> Simon
> >>   
> >>
> >> ----- Original Message -----
> >>> From: "Avi Tal" <atal at redhat.com>
> >>> To: "Yaniv Kaul" <ykaul at redhat.com>
> >>> Cc: engine-devel at ovirt.org
> >>> Sent: Monday, September 24, 2012 10:13:52 AM
> >>> Subject: Re: [Engine-devel] RFE: Netwrok Main Tab
> >>>
> >>>
> >>>
> >>> ----- Original Message -----
> >>>> From: "Yaniv Kaul" <ykaul at redhat.com>
> >>>> To: "Moti Asayag" <masayag at redhat.com>
> >>>> Cc: engine-devel at ovirt.org
> >>>> Sent: Sunday, September 23, 2012 6:16:47 PM
> >>>> Subject: Re: [Engine-devel] RFE: Netwrok Main Tab
> >>>>
> >>>> On 09/23/2012 06:12 PM, Moti Asayag wrote:
> >>>>> On 09/23/2012 05:01 PM, Yaniv Kaul wrote:
> >>>>>> On 09/23/2012 04:55 PM, Alona Kaplan wrote:
> >>>>>>> ----- Original Message -----
> >>>>>>>> From: "Avi Tal" <atal at redhat.com>
> >>>>>>>> To: "Alona Kaplan" <alkaplan at redhat.com>
> >>>>>>>> Cc: engine-devel at ovirt.org
> >>>>>>>> Sent: Sunday, September 23, 2012 4:17:26 PM
> >>>>>>>> Subject: Re: [Engine-devel] RFE: Netwrok Main Tab
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> ----- Original Message -----
> >>>>>>>>> From: "Alona Kaplan" <alkaplan at redhat.com>
> >>>>>>>>> To: "Avi Tal" <atal at redhat.com>
> >>>>>>>>> Cc: engine-devel at ovirt.org
> >>>>>>>>> Sent: Sunday, September 23, 2012 1:31:32 PM
> >>>>>>>>> Subject: Re: [Engine-devel] RFE: Netwrok Main Tab
> >>>>>>>>>
> >>>>>>>>> 1. What actions do you suggest to add?
> >>>>>>>> Add, Edit and remove actions of each component.
> >>>>>>>>
> >>>>>>> Host:
> >>>>>>> Add- What will add action on Networks->Hosts sub tab do?
> >>>>>>> Choose
> >>>>>>> an
> >>>>>>> existing host and attach the network to one of its nics?
> >>>>>>> How will it work? after choosing the host you will open
> >>>>>>> setupNetworks
> >>>>>>> window and just enable dragging of the selected network (in
> >>>>>>> the
> >>>>>>> main
> >>>>>>> tab) to a nic? I think it is too much.
> >>>>>>>
> >>>>>>> Edit- same as add.
> >>>>>>>
> >>>>>>> Remove- What is the meaning of Remove host in network's
> >>>>>>> context?
> >>>>>>> The
> >>>>>>> network will be detached from the host? I think it is
> >>>>>>> confusing.
> >>>>>>>
> >>>>>>> Vm/Template:
> >>>>>>> Add: What will it do? You will choose a vm and then add a
> >>>>>>> vnic
> >>>>>>> to
> >>>>>>> the
> >>>>>>> vm? Where will you see the vnic details?
> >>>>>>> Edit: Same as add.
> >>>>>>> Remove: You will remove all the vnics that use the selected
> >>>>>>> network
> >>>>>>> from the vm? Or do you mean to add a remove per vnic?
> >>>>>> For all the above: yes.
> >>>>>> We can certainly work on the small details, but having a main
> >>>>>> tab
> >>>>>> with
> >>>>>> little to no action whatsoever is kinda disappointing.
> >>>>> IMO adding 'assign' action in the main tab might be handy in
> >>>>> order
> >>>>> to
> >>>>> assign a single network in a single dialog to several clusters.
> >>>>>
> >>>>> However It is not clear to me how Add/Edit for a VM in a
> >>>>> sub-tab
> >>>>> should
> >>>>> look like. The VM should have a list of interfaces (represented
> >>>>> as
> >>>>> sub
> >>>>> collection/tree).
> >>>> I was thinking more of right-click on the network, selecting
> >>>> 'Add
> >>>> to
> >>>> VM'
> >>>> and then selecting single/mutliple VMs from a dialog with all
> >>>> the
> >>>> VMs
> >>>> (yes, filtered via search).
> >>>> Y.
> >>>>
> >>> +1
> >>>
> >>>>> What will be the meaning of 'Add' in that context? Since the VM
> >>>>> already
> >>>>> have a vNIC attached to that network. If adding another once,
> >>>>> it
> >>>>> should
> >>>>> be enabled on the record representing the VM itself which will
> >>>>> confuse
> >>>>> the user.
> >>>>> Same goes for 'Edit' of a VM interface under a context of a
> >>>>> specific
> >>>>> network: in the current 'Edit VM Interface' you can change the
> >>>>> network.
> >>>>> Should the same dialog be used here as well?
> >>>>>
> >>>>> The 'Remove' option is the clearer action on this context.
> >>>>>
> >>>>>
> >>>>>> (example of 'small details' - yes, when clicking remove for a
> >>>>>> VM/template - it will remove all vNICs that use that network
> >>>>>> from
> >>>>>> the
> >>>>>> VM. A VM with more than one vNIC on the same network is not
> >>>>>> the
> >>>>>> common
> >>>>>> case anyway, and if you want to remove just a single vNIC, go
> >>>>>> to
> >>>>>> the
> >>>>>> VM). I think we can also live with Add/Remove only, and
> >>>>>> 'defer'
> >>>>>> the edit
> >>>>>> actions to the respectable objects (host/vm/template) edit
> >>>>>> dialog
> >>>>>> boxes
> >>>>>> that originates from their own main tab.
> >>>>>>
> >>>>>> Y.
> >>>>>>
> >>>>>>>>> 2. I don't understand your suggestion. You mean add
> >>>>>>>>> SetupNetworks
> >>>>>>>>> to
> >>>>>>>>> the Networks main tab?
> >>>>>>>> No.
> >>>>>>>> Just Thinking of a nice display which will present logical
> >>>>>>>> network
> >>>>>>>> and his connected host/vm configuration instead of passing
> >>>>>>>> through
> >>>>>>>> dub-tabs
> >>>>>>>> I should give it a deeper thought.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> ----- Original Message -----
> >>>>>>>>>> From: "Avi Tal" <atal at redhat.com>
> >>>>>>>>>> To: "Alona Kaplan" <alkaplan at redhat.com>
> >>>>>>>>>> Cc: engine-devel at ovirt.org
> >>>>>>>>>> Sent: Thursday, September 20, 2012 6:58:05 PM
> >>>>>>>>>> Subject: Re: [Engine-devel] RFE: Netwrok Main Tab
> >>>>>>>>>>
> >>>>>>>>>> 1. Why not having Actions for Hosts, Vms and Templates ?
> >>>>>>>>>> I believe we should have those actions instead of making
> >>>>>>>>>> the
> >>>>>>>>>> user
> >>>>>>>>>> browse between 'network -> vms -> network (sub tab)' just
> >>>>>>>>>> in
> >>>>>>>>>> order
> >>>>>>>>>> to update VM's network.
> >>>>>>>>>>
> >>>>>>>>>> 2. Why having such a big window which most of the time
> >>>>>>>>>> will
> >>>>>>>>>> be
> >>>>>>>>>> empty?
> >>>>>>>>>>       How many logical network would be existed in the
> >>>>>>>>>>       system?
> >>>>>>>>>>       My suggestion is to go for more graphical window
> >>>>>>>>>>       which
> >>>>>>>>>>       will
> >>>>>>>>>>       present:
> >>>>>>>>>>       A. logical networks
> >>>>>>>>>>       B. Multiple networks with the host configurations at
> >>>>>>>>>>       the
> >>>>>>>>>>       same
> >>>>>>>>>>       window: very important because most of the System
> >>>>>>>>>>       admins
> >>>>>>>>>>       would
> >>>>>>>>>>       like to have a bigger picture of the entire network
> >>>>>>>>>>       configuration
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> ----- Original Message -----
> >>>>>>>>>> From: "Alona Kaplan" <alkaplan at redhat.com>
> >>>>>>>>>> To: engine-devel at ovirt.org
> >>>>>>>>>> Sent: Thursday, September 20, 2012 1:50:15 PM
> >>>>>>>>>> Subject: [Engine-devel] RFE: Netwrok Main Tab
> >>>>>>>>>>
> >>>>>>>>>> Hi all,
> >>>>>>>>>>
> >>>>>>>>>> Please review the wiki and add your comments.
> >>>>>>>>>>
> >>>>>>>>>> http://wiki.ovirt.org/wiki/Feature/NetworkMainTab
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> RFE:
> >>>>>>>>>> https://bugzilla.redhat.com/858742
> >>>>>>>>>>
> >>>>>>>>>> Thanks,
> >>>>>>>>>> Alona.
> >>>>>>>>>> _______________________________________________
> >>>>>>>>>> Engine-devel mailing list
> >>>>>>>>>> Engine-devel at ovirt.org
> >>>>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>>>>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> Engine-devel mailing list
> >>>>>>> Engine-devel at ovirt.org
> >>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>>>>> _______________________________________________
> >>>>>> Engine-devel mailing list
> >>>>>> Engine-devel at ovirt.org
> >>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>>> _______________________________________________
> >>>> Engine-devel mailing list
> >>>> Engine-devel at ovirt.org
> >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>>>
> >>> _______________________________________________
> >>> Engine-devel mailing list
> >>> Engine-devel at ovirt.org
> >>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>>
> 
> 


From nslomian at redhat.com  Wed Oct 10 09:23:12 2012
From: nslomian at redhat.com (Noam Slomianko)
Date: Wed, 10 Oct 2012 05:23:12 -0400 (EDT)
Subject: [Engine-devel] Mom Balloon policy issue
In-Reply-To: <20121009180602.GH25171@aglitke>
Message-ID: <414657630.10706381.1349860992830.JavaMail.root@redhat.com>

Regarding qemu-kvm memory allocation behaviour, this is the clearest explanation I found:

"Unless using explicit hugepages for the guest, KVM will
*not* initially allocate all RAM from the host OS. Each
page of RAM is only allocated when the guest OS touches
that page. So if you set memory=8G and currentMemory=4G,
although you might expect resident usage of KVM on the
host to be 4 G, it can in fact be pretty much any value
between 0 and 4 GB depending on whether the guest OS
has touched the memory pages, or as much as 8 GB if the
guest OS has no balloon driver and touches all memory
immediately."[1]

And as far as I've seen it behave the same after the guest is ballooned and then deflated.

Conclusion, the time in which the guest is allocated the resident memory is not deterministic and dependent on use and OS 
For example Windows7 uses all available memory as cache while fedora does not.
So an inactive guest running windows7 will consume all possible resident memory right away while an inactive guest running fedora might never grow in memory size.

[1] http://www.redhat.com/archives/virt-tools-list/2011-January/msg00001.html

------------------
Noam Slomianko
Red Hat Enterprise Virtualization, SLA team

----- Original Message -----
From: "Adam Litke" <agl at us.ibm.com>
To: "Noam Slomianko" <nslomian at redhat.com>
Cc: "Doron Fediuck" <dfediuck at redhat.com>, vdsm-devel at lists.fedorahosted.org, engine-devel at ovirt.org
Sent: Tuesday, October 9, 2012 8:06:02 PM
Subject: Re: Mom Balloon policy issue

Thanks for writing this.  Some thoughts inline, below.  Also, cc'ing some lists
in case other folks want to participate in the discussion.

On Tue, Oct 09, 2012 at 01:12:30PM -0400, Noam Slomianko wrote:
> Greetings,
> 
> I've fiddled around with ballooning and wanted to raise a question for debate.
> 
> Currently as long as the host is under memory pressure, MOM will try and reclaim back memory from all guests with more free memory then a given threshold.
> 
> Main issue: Guest allocated memory is not the same as the resident (physical) memory used by qemu.
> This means that when memory is reclaimed back (the balloon is inflated) we might not get as much memory as planed back (or non at all).
> 
>  *Example1 no memory is reclaimed back:
>     name | allocated memory | used by the vm | resident memory used in the host by qemu
>     Vm1  |       4G         |       4G,      |                4G
>     Vm2  |       4G         |       1G       |                1G
>  - MOM will inflate the balloon in vm2 (as vm has no free memory) and will gain no memory

One thing to keep in mind is that VMs having less host RSS than their memory
allocation is a temporary condition.  All VMs will eventually consume their full
allocation if allowed to run.  I'd be curious to know how long this process
takes in general.

We might be able to handle this case by refusing to inflate the balloon if:
    (VM free memory - planned balloon inflation) > host RSS


>  *Example1 memory is reclaimed partially:
>     name | allocated memory | used by the vm | resident memory used in the host by qemu
>     Vm1  |       4G         |       4G,      |                4G
>     Vm2  |       4G         |       1G       |                1G
>     Vm3  |       4G         |       1G       |                4G
>  - MOM will inflate the balloon in vm2 and vm3 slowly gaining only from vm3

The above rule extension may help here too.

> this behaviour might in the cause us to:
>  * spend time reclaiming memory from many guests when we can reclaim only from a subgroup
>  * be under the impression that we have more potential memory to reclaim when we do
>  * bring inactive VMs dangerously low as they are constantly reclaimed (I've had guests crashing from kernel out of memory)
> 
> 
> To address this I suggest that we collect guest memory stats from libvirt as well, so we have the option to use them in our calculations.
> This can be achieved with the command "virsh dommemstat <domain>" which returns
>     actual 3915372 (allocated)
>     rss 2141580 (resident memory used by qemu)

I would suggest adding these two fields to the VmStats that are collected by
vdsm.  Then, to try it out, add the fields to the GuestMemory Collector.  (Note:
MOM does have a collector that gathers RSS for VMs.  It's called GuestQemuProc).
You can then extend the Balloon policy to add a snippet to check if the proposed
balloon adjustment should be carried out.  You could add the logic to the
change_big_enough function.

> additional topic:
>  * should we include per guest config (for example a hard minimum memory cap, this vm cannot run effectively with less then 1G memory)

Yes.  This is probably something we want to do.  There is a whole topic around
VM tagging that we should consider.  In the future we will want to be able to do
many different things in policy based on a VMs tag.  For example, some VMs may
be completely exempt from ballooning.  Others may have a minimum limit.

I want to avoid passing in the raw guest configuration because MOM needs to work
with direct libvirt vms and with ovirt/vdsm vms.  Therefore, we want to think
carefully about the abstractions we use when presenting VM properties to MOM.

-- 
Adam Litke <agl at us.ibm.com>
IBM Linux Technology Center



From ykaul at redhat.com  Wed Oct 10 09:33:20 2012
From: ykaul at redhat.com (Yaniv Kaul)
Date: Wed, 10 Oct 2012 11:33:20 +0200
Subject: [Engine-devel] Mom Balloon policy issue
In-Reply-To: <414657630.10706381.1349860992830.JavaMail.root@redhat.com>
References: <414657630.10706381.1349860992830.JavaMail.root@redhat.com>
Message-ID: <507540E0.1010507@redhat.com>

On 10/10/2012 11:23 AM, Noam Slomianko wrote:
> Regarding qemu-kvm memory allocation behaviour, this is the clearest explanation I found:
>
> "Unless using explicit hugepages for the guest, KVM will
> *not* initially allocate all RAM from the host OS. Each
> page of RAM is only allocated when the guest OS touches
> that page. So if you set memory=8G and currentMemory=4G,
> although you might expect resident usage of KVM on the
> host to be 4 G, it can in fact be pretty much any value
> between 0 and 4 GB depending on whether the guest OS
> has touched the memory pages, or as much as 8 GB if the
> guest OS has no balloon driver and touches all memory
> immediately."[1]

Windows zeros out all memory on startup, so it essentially touches all 
of its pages right away.
Y.

>
> And as far as I've seen it behave the same after the guest is ballooned and then deflated.
>
> Conclusion, the time in which the guest is allocated the resident memory is not deterministic and dependent on use and OS
> For example Windows7 uses all available memory as cache while fedora does not.
> So an inactive guest running windows7 will consume all possible resident memory right away while an inactive guest running fedora might never grow in memory size.
>
> [1] http://www.redhat.com/archives/virt-tools-list/2011-January/msg00001.html
>
> ------------------
> Noam Slomianko
> Red Hat Enterprise Virtualization, SLA team
>
> ----- Original Message -----
> From: "Adam Litke" <agl at us.ibm.com>
> To: "Noam Slomianko" <nslomian at redhat.com>
> Cc: "Doron Fediuck" <dfediuck at redhat.com>, vdsm-devel at lists.fedorahosted.org, engine-devel at ovirt.org
> Sent: Tuesday, October 9, 2012 8:06:02 PM
> Subject: Re: Mom Balloon policy issue
>
> Thanks for writing this.  Some thoughts inline, below.  Also, cc'ing some lists
> in case other folks want to participate in the discussion.
>
> On Tue, Oct 09, 2012 at 01:12:30PM -0400, Noam Slomianko wrote:
>> Greetings,
>>
>> I've fiddled around with ballooning and wanted to raise a question for debate.
>>
>> Currently as long as the host is under memory pressure, MOM will try and reclaim back memory from all guests with more free memory then a given threshold.
>>
>> Main issue: Guest allocated memory is not the same as the resident (physical) memory used by qemu.
>> This means that when memory is reclaimed back (the balloon is inflated) we might not get as much memory as planed back (or non at all).
>>
>>   *Example1 no memory is reclaimed back:
>>      name | allocated memory | used by the vm | resident memory used in the host by qemu
>>      Vm1  |       4G         |       4G,      |                4G
>>      Vm2  |       4G         |       1G       |                1G
>>   - MOM will inflate the balloon in vm2 (as vm has no free memory) and will gain no memory
> One thing to keep in mind is that VMs having less host RSS than their memory
> allocation is a temporary condition.  All VMs will eventually consume their full
> allocation if allowed to run.  I'd be curious to know how long this process
> takes in general.
>
> We might be able to handle this case by refusing to inflate the balloon if:
>      (VM free memory - planned balloon inflation) > host RSS
>
>
>>   *Example1 memory is reclaimed partially:
>>      name | allocated memory | used by the vm | resident memory used in the host by qemu
>>      Vm1  |       4G         |       4G,      |                4G
>>      Vm2  |       4G         |       1G       |                1G
>>      Vm3  |       4G         |       1G       |                4G
>>   - MOM will inflate the balloon in vm2 and vm3 slowly gaining only from vm3
> The above rule extension may help here too.
>
>> this behaviour might in the cause us to:
>>   * spend time reclaiming memory from many guests when we can reclaim only from a subgroup
>>   * be under the impression that we have more potential memory to reclaim when we do
>>   * bring inactive VMs dangerously low as they are constantly reclaimed (I've had guests crashing from kernel out of memory)
>>
>>
>> To address this I suggest that we collect guest memory stats from libvirt as well, so we have the option to use them in our calculations.
>> This can be achieved with the command "virsh dommemstat <domain>" which returns
>>      actual 3915372 (allocated)
>>      rss 2141580 (resident memory used by qemu)
> I would suggest adding these two fields to the VmStats that are collected by
> vdsm.  Then, to try it out, add the fields to the GuestMemory Collector.  (Note:
> MOM does have a collector that gathers RSS for VMs.  It's called GuestQemuProc).
> You can then extend the Balloon policy to add a snippet to check if the proposed
> balloon adjustment should be carried out.  You could add the logic to the
> change_big_enough function.
>
>> additional topic:
>>   * should we include per guest config (for example a hard minimum memory cap, this vm cannot run effectively with less then 1G memory)
> Yes.  This is probably something we want to do.  There is a whole topic around
> VM tagging that we should consider.  In the future we will want to be able to do
> many different things in policy based on a VMs tag.  For example, some VMs may
> be completely exempt from ballooning.  Others may have a minimum limit.
>
> I want to avoid passing in the raw guest configuration because MOM needs to work
> with direct libvirt vms and with ovirt/vdsm vms.  Therefore, we want to think
> carefully about the abstractions we use when presenting VM properties to MOM.
>



From iheim at redhat.com  Wed Oct 10 07:35:36 2012
From: iheim at redhat.com (Itamar Heim)
Date: Wed, 10 Oct 2012 09:35:36 +0200
Subject: [Engine-devel] oVirt UI Plugins Presentation: PDF slides
In-Reply-To: <412710972.6212909.1349779168314.JavaMail.root@redhat.com>
References: <412710972.6212909.1349779168314.JavaMail.root@redhat.com>
Message-ID: <50752548.4050802@redhat.com>

On 10/09/2012 12:39 PM, Vojtech Szocs wrote:
> Hi guys,
>
> please find the slides for today's UI Plugins presentation attached to this email.
>
> Regards,
> Vojtech
>
>
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>

great deck!

few comments/questions:
1. you are using internal entities ("VDS") - the ui API must only use
    entities and actions which match the REST API entities/actions.
    or to begin with, make all these entities share IEntity, and just
    pass the IEntity.EntityId property for them to the plugin).
2. slides 21-25
    iiuc, these are part of the plugin api infrastrcture, not of a
    sample plugin. i think a sample, simple, javascript plugin git repo
    would be great (like we have sample hooks for vdsm).
3. nit(?): the event you fire in the sample is not HostActivated,
    rather HostActivateRequest? i.e., need to distinguish between a
    request for an action, to a real status change of an object (which
    would be a change for a host entity in the grid from one status to a
    another status)?


From simon at redhat.com  Wed Oct 10 11:40:18 2012
From: simon at redhat.com (Simon Grinberg)
Date: Wed, 10 Oct 2012 07:40:18 -0400 (EDT)
Subject: [Engine-devel] RFE: Netwrok Main Tab
In-Reply-To: <662323620.10689197.1349858390348.JavaMail.root@redhat.com>
Message-ID: <1987850394.9860939.1349869218147.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Alona Kaplan" <alkaplan at redhat.com>
> To: "Simon Grinberg" <sgrinber at redhat.com>
> Cc: engine-devel at ovirt.org, "Muli Salem" <msalem at redhat.com>, "Moti Asayag" <masayag at redhat.com>, "Avi Tal"
> <atal at redhat.com>, "Yaniv Kaul" <ykaul at redhat.com>
> Sent: Wednesday, October 10, 2012 10:39:50 AM
> Subject: Re: [Engine-devel] RFE: Netwrok Main Tab
> 
> I agree.
> 
> Simon, what do you think?
> 
> ----- Original Message -----
> > From: "Yaniv Kaul" <ykaul at redhat.com>
> > To: "Alona Kaplan" <alkaplan at redhat.com>
> > Cc: engine-devel at ovirt.org, "Muli Salem" <msalem at redhat.com>, "Moti
> > Asayag" <masayag at redhat.com>, "Avi Tal"
> > <atal at redhat.com>, "Simon Grinberg" <sgrinber at redhat.com>
> > Sent: Tuesday, October 9, 2012 5:01:39 PM
> > Subject: Re: [Engine-devel] RFE: Netwrok Main Tab
> > 
> > On 10/09/2012 11:34 AM, Alona Kaplan wrote:
> > > The wiki was updated with the final design.
> > > http://wiki.ovirt.org/wiki/Feature/NetworkMainTab
> > >
> > > Thanks for the comments,
> > > Alona.
> > 
> > Is the general sub-tab providing any information not available in
> > the
> > grid already?
> > If not, lets drop it.

How complicated it will be to re-add it later?

There is no added information in this tab since right now there is not much to report, everything can easily fit into the columns. But thinking forward you may have other values and properties.

Just throwing some here not necessary for the near future so don't be alarmed, some may not/probably won't land in the general tab or the network main tab:
- VM network / Storage / Migration / Management (*PS what is the current indication in this tab for management networks except for their names?)
- Provider type - like external manager (Plug-in)/internal/etc (not sure it's a main tab item, but ... )
- Mutually exclusive? Redundancy? other properties.
- Last modified by ___ (It's a property that I would have loved to see on all objects instead of searching the event log)
- Modification date 
- Global SLA Policy (for hierarchical SLA)  

I think you got the drift
And let's not forget 'Description' may not fully fit in it's column  

I think it's worth to have it now then to add it later when the need compels it. But not feeling too strongly one way or the other. 


> > And while it's also consistent to show the clusters as the second
> > (or
> > now, after the above suggestion first) sub-tab, it's not an
> > interesting
> > tab. I suggest the default when clicking on a network is to show
> > the
> > VMs
> > tab (so while the order of the tabs is not changed, the default
> > shown
> > is).

+1 

> > Y.
> > 
> > 
> > >
> > > ----- Original Message -----
> > >> From: "Simon Grinberg" <simon at redhat.com>
> > >> To: "Alona Kaplan" <alkaplan at redhat.com>
> > >> Cc: engine-devel at ovirt.org
> > >> Sent: Tuesday, October 2, 2012 7:36:44 PM
> > >> Subject: Re: [Engine-devel] RFE: Netwrok Main Tab
> > >>
> > >> Trying to sum up some of the suggestions ('coincidently'
> > >> dropping
> > >> those which I think a bit too much for first implementation :))
> > >> and
> > >> add some suggestions of my own
> > >>
> > >> 1. On the hosts subtab:
> > >>     1.1 Have a radio button that will show either
> > >>         1.1.1 All the hosts that this network is attached to
> > >>         1.1.2 All the hosts where this network attached to the
> > >>         cluster
> > >>         but not to the host (Very important for non-required
> > >>         where
> > >>         the host status does not indicate something is missing)
> > >>     1.2 Have a remove button for 1.1.1, ManageNetworks button
> > >>     for
> > >>     1.1.2. Simple add will not do since you don't know where to
> > >>     add.
> > >>
> > >> 2. On the vms subtab
> > >>     2.1 Have a radio button that will show either
> > >>         2.1.1 All the vms that this network is attached to
> > >>         2.1.2 All the vms where this network is not attached to
> > >>     2.2 Have a 'remove' button for 2.1.1, Have 'add' button for
> > >>     2.1.2
> > >>     2.3 Allow multiple selection for both actions of 2.2
> > >>     2.4 Add remove from all button.
> > >>     2.5 I would not bother to show all the nics attached to the
> > >>     VM
> > >>     from the same network, it's too rare. Just make sure there
> > >>     is
> > >>     no
> > >>     exception if this does exist. So the columns should have
> > >>     'nic'
> > >>     as
> > >>     the first and there should be only one VM per line. If there
> > >>     are
> > >>     more then one nic per VM then just indicate 'multiple'
> > >>
> > >> 3. Templates subtab - same as VM, drop the expansion of the NICs
> > >> list.
> > >>
> > >> 4. Clusters subtab
> > >>     Allow assign to multiple clusters - same as the edit in the
> > >>     data
> > >>     center tab (Just use the same dialogue)
> > >>
> > >> 5. Main: You have enough space then why not add the MTU column?
> > >>
> > >> 6. Queries for the sub tabs: For each needs the reverse query as
> > >> well
> > >> (Probably more important when adding new network)
> > >>
> > >>
> > >> Oops, I think I mostly added and dropped (almost) nothing :)
> > >>
> > >> Regards,
> > >> Simon
> > >>   
> > >>
> > >> ----- Original Message -----
> > >>> From: "Avi Tal" <atal at redhat.com>
> > >>> To: "Yaniv Kaul" <ykaul at redhat.com>
> > >>> Cc: engine-devel at ovirt.org
> > >>> Sent: Monday, September 24, 2012 10:13:52 AM
> > >>> Subject: Re: [Engine-devel] RFE: Netwrok Main Tab
> > >>>
> > >>>
> > >>>
> > >>> ----- Original Message -----
> > >>>> From: "Yaniv Kaul" <ykaul at redhat.com>
> > >>>> To: "Moti Asayag" <masayag at redhat.com>
> > >>>> Cc: engine-devel at ovirt.org
> > >>>> Sent: Sunday, September 23, 2012 6:16:47 PM
> > >>>> Subject: Re: [Engine-devel] RFE: Netwrok Main Tab
> > >>>>
> > >>>> On 09/23/2012 06:12 PM, Moti Asayag wrote:
> > >>>>> On 09/23/2012 05:01 PM, Yaniv Kaul wrote:
> > >>>>>> On 09/23/2012 04:55 PM, Alona Kaplan wrote:
> > >>>>>>> ----- Original Message -----
> > >>>>>>>> From: "Avi Tal" <atal at redhat.com>
> > >>>>>>>> To: "Alona Kaplan" <alkaplan at redhat.com>
> > >>>>>>>> Cc: engine-devel at ovirt.org
> > >>>>>>>> Sent: Sunday, September 23, 2012 4:17:26 PM
> > >>>>>>>> Subject: Re: [Engine-devel] RFE: Netwrok Main Tab
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> ----- Original Message -----
> > >>>>>>>>> From: "Alona Kaplan" <alkaplan at redhat.com>
> > >>>>>>>>> To: "Avi Tal" <atal at redhat.com>
> > >>>>>>>>> Cc: engine-devel at ovirt.org
> > >>>>>>>>> Sent: Sunday, September 23, 2012 1:31:32 PM
> > >>>>>>>>> Subject: Re: [Engine-devel] RFE: Netwrok Main Tab
> > >>>>>>>>>
> > >>>>>>>>> 1. What actions do you suggest to add?
> > >>>>>>>> Add, Edit and remove actions of each component.
> > >>>>>>>>
> > >>>>>>> Host:
> > >>>>>>> Add- What will add action on Networks->Hosts sub tab do?
> > >>>>>>> Choose
> > >>>>>>> an
> > >>>>>>> existing host and attach the network to one of its nics?
> > >>>>>>> How will it work? after choosing the host you will open
> > >>>>>>> setupNetworks
> > >>>>>>> window and just enable dragging of the selected network (in
> > >>>>>>> the
> > >>>>>>> main
> > >>>>>>> tab) to a nic? I think it is too much.
> > >>>>>>>
> > >>>>>>> Edit- same as add.
> > >>>>>>>
> > >>>>>>> Remove- What is the meaning of Remove host in network's
> > >>>>>>> context?
> > >>>>>>> The
> > >>>>>>> network will be detached from the host? I think it is
> > >>>>>>> confusing.
> > >>>>>>>
> > >>>>>>> Vm/Template:
> > >>>>>>> Add: What will it do? You will choose a vm and then add a
> > >>>>>>> vnic
> > >>>>>>> to
> > >>>>>>> the
> > >>>>>>> vm? Where will you see the vnic details?
> > >>>>>>> Edit: Same as add.
> > >>>>>>> Remove: You will remove all the vnics that use the selected
> > >>>>>>> network
> > >>>>>>> from the vm? Or do you mean to add a remove per vnic?
> > >>>>>> For all the above: yes.
> > >>>>>> We can certainly work on the small details, but having a
> > >>>>>> main
> > >>>>>> tab
> > >>>>>> with
> > >>>>>> little to no action whatsoever is kinda disappointing.
> > >>>>> IMO adding 'assign' action in the main tab might be handy in
> > >>>>> order
> > >>>>> to
> > >>>>> assign a single network in a single dialog to several
> > >>>>> clusters.
> > >>>>>
> > >>>>> However It is not clear to me how Add/Edit for a VM in a
> > >>>>> sub-tab
> > >>>>> should
> > >>>>> look like. The VM should have a list of interfaces
> > >>>>> (represented
> > >>>>> as
> > >>>>> sub
> > >>>>> collection/tree).
> > >>>> I was thinking more of right-click on the network, selecting
> > >>>> 'Add
> > >>>> to
> > >>>> VM'
> > >>>> and then selecting single/mutliple VMs from a dialog with all
> > >>>> the
> > >>>> VMs
> > >>>> (yes, filtered via search).
> > >>>> Y.
> > >>>>
> > >>> +1
> > >>>
> > >>>>> What will be the meaning of 'Add' in that context? Since the
> > >>>>> VM
> > >>>>> already
> > >>>>> have a vNIC attached to that network. If adding another once,
> > >>>>> it
> > >>>>> should
> > >>>>> be enabled on the record representing the VM itself which
> > >>>>> will
> > >>>>> confuse
> > >>>>> the user.
> > >>>>> Same goes for 'Edit' of a VM interface under a context of a
> > >>>>> specific
> > >>>>> network: in the current 'Edit VM Interface' you can change
> > >>>>> the
> > >>>>> network.
> > >>>>> Should the same dialog be used here as well?
> > >>>>>
> > >>>>> The 'Remove' option is the clearer action on this context.
> > >>>>>
> > >>>>>
> > >>>>>> (example of 'small details' - yes, when clicking remove for
> > >>>>>> a
> > >>>>>> VM/template - it will remove all vNICs that use that network
> > >>>>>> from
> > >>>>>> the
> > >>>>>> VM. A VM with more than one vNIC on the same network is not
> > >>>>>> the
> > >>>>>> common
> > >>>>>> case anyway, and if you want to remove just a single vNIC,
> > >>>>>> go
> > >>>>>> to
> > >>>>>> the
> > >>>>>> VM). I think we can also live with Add/Remove only, and
> > >>>>>> 'defer'
> > >>>>>> the edit
> > >>>>>> actions to the respectable objects (host/vm/template) edit
> > >>>>>> dialog
> > >>>>>> boxes
> > >>>>>> that originates from their own main tab.
> > >>>>>>
> > >>>>>> Y.
> > >>>>>>
> > >>>>>>>>> 2. I don't understand your suggestion. You mean add
> > >>>>>>>>> SetupNetworks
> > >>>>>>>>> to
> > >>>>>>>>> the Networks main tab?
> > >>>>>>>> No.
> > >>>>>>>> Just Thinking of a nice display which will present logical
> > >>>>>>>> network
> > >>>>>>>> and his connected host/vm configuration instead of passing
> > >>>>>>>> through
> > >>>>>>>> dub-tabs
> > >>>>>>>> I should give it a deeper thought.
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>> ----- Original Message -----
> > >>>>>>>>>> From: "Avi Tal" <atal at redhat.com>
> > >>>>>>>>>> To: "Alona Kaplan" <alkaplan at redhat.com>
> > >>>>>>>>>> Cc: engine-devel at ovirt.org
> > >>>>>>>>>> Sent: Thursday, September 20, 2012 6:58:05 PM
> > >>>>>>>>>> Subject: Re: [Engine-devel] RFE: Netwrok Main Tab
> > >>>>>>>>>>
> > >>>>>>>>>> 1. Why not having Actions for Hosts, Vms and Templates ?
> > >>>>>>>>>> I believe we should have those actions instead of making
> > >>>>>>>>>> the
> > >>>>>>>>>> user
> > >>>>>>>>>> browse between 'network -> vms -> network (sub tab)'
> > >>>>>>>>>> just
> > >>>>>>>>>> in
> > >>>>>>>>>> order
> > >>>>>>>>>> to update VM's network.
> > >>>>>>>>>>
> > >>>>>>>>>> 2. Why having such a big window which most of the time
> > >>>>>>>>>> will
> > >>>>>>>>>> be
> > >>>>>>>>>> empty?
> > >>>>>>>>>>       How many logical network would be existed in the
> > >>>>>>>>>>       system?
> > >>>>>>>>>>       My suggestion is to go for more graphical window
> > >>>>>>>>>>       which
> > >>>>>>>>>>       will
> > >>>>>>>>>>       present:
> > >>>>>>>>>>       A. logical networks
> > >>>>>>>>>>       B. Multiple networks with the host configurations
> > >>>>>>>>>>       at
> > >>>>>>>>>>       the
> > >>>>>>>>>>       same
> > >>>>>>>>>>       window: very important because most of the System
> > >>>>>>>>>>       admins
> > >>>>>>>>>>       would
> > >>>>>>>>>>       like to have a bigger picture of the entire
> > >>>>>>>>>>       network
> > >>>>>>>>>>       configuration
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>> ----- Original Message -----
> > >>>>>>>>>> From: "Alona Kaplan" <alkaplan at redhat.com>
> > >>>>>>>>>> To: engine-devel at ovirt.org
> > >>>>>>>>>> Sent: Thursday, September 20, 2012 1:50:15 PM
> > >>>>>>>>>> Subject: [Engine-devel] RFE: Netwrok Main Tab
> > >>>>>>>>>>
> > >>>>>>>>>> Hi all,
> > >>>>>>>>>>
> > >>>>>>>>>> Please review the wiki and add your comments.
> > >>>>>>>>>>
> > >>>>>>>>>> http://wiki.ovirt.org/wiki/Feature/NetworkMainTab
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>> RFE:
> > >>>>>>>>>> https://bugzilla.redhat.com/858742
> > >>>>>>>>>>
> > >>>>>>>>>> Thanks,
> > >>>>>>>>>> Alona.
> > >>>>>>>>>> _______________________________________________
> > >>>>>>>>>> Engine-devel mailing list
> > >>>>>>>>>> Engine-devel at ovirt.org
> > >>>>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> > >>>>>>>>>>
> > >>>>>>> _______________________________________________
> > >>>>>>> Engine-devel mailing list
> > >>>>>>> Engine-devel at ovirt.org
> > >>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> > >>>>>> _______________________________________________
> > >>>>>> Engine-devel mailing list
> > >>>>>> Engine-devel at ovirt.org
> > >>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> > >>>> _______________________________________________
> > >>>> Engine-devel mailing list
> > >>>> Engine-devel at ovirt.org
> > >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> > >>>>
> > >>> _______________________________________________
> > >>> Engine-devel mailing list
> > >>> Engine-devel at ovirt.org
> > >>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> > >>>
> > 
> > 
> 


From alkaplan at redhat.com  Wed Oct 10 12:12:10 2012
From: alkaplan at redhat.com (Alona Kaplan)
Date: Wed, 10 Oct 2012 08:12:10 -0400 (EDT)
Subject: [Engine-devel] RFE: Netwrok Main Tab
In-Reply-To: <1987850394.9860939.1349869218147.JavaMail.root@redhat.com>
Message-ID: <795625706.10763572.1349871130460.JavaMail.root@redhat.com>

So the conclusion is to leave the General tab but make the vm tab the default one?

There is no indication for the management networks except of the name. The name can be bold or we can add extra column to indicate it.

----- Original Message -----
> From: "Simon Grinberg" <simon at redhat.com>
> To: "Alona Kaplan" <alkaplan at redhat.com>
> Cc: engine-devel at ovirt.org, "Muli Salem" <msalem at redhat.com>, "Moti Asayag" <masayag at redhat.com>, "Avi Tal"
> <atal at redhat.com>, "Yaniv Kaul" <ykaul at redhat.com>
> Sent: Wednesday, October 10, 2012 1:40:18 PM
> Subject: Re: [Engine-devel] RFE: Netwrok Main Tab
> 
> 
> 
> ----- Original Message -----
> > From: "Alona Kaplan" <alkaplan at redhat.com>
> > To: "Simon Grinberg" <sgrinber at redhat.com>
> > Cc: engine-devel at ovirt.org, "Muli Salem" <msalem at redhat.com>, "Moti
> > Asayag" <masayag at redhat.com>, "Avi Tal"
> > <atal at redhat.com>, "Yaniv Kaul" <ykaul at redhat.com>
> > Sent: Wednesday, October 10, 2012 10:39:50 AM
> > Subject: Re: [Engine-devel] RFE: Netwrok Main Tab
> > 
> > I agree.
> > 
> > Simon, what do you think?
> > 
> > ----- Original Message -----
> > > From: "Yaniv Kaul" <ykaul at redhat.com>
> > > To: "Alona Kaplan" <alkaplan at redhat.com>
> > > Cc: engine-devel at ovirt.org, "Muli Salem" <msalem at redhat.com>,
> > > "Moti
> > > Asayag" <masayag at redhat.com>, "Avi Tal"
> > > <atal at redhat.com>, "Simon Grinberg" <sgrinber at redhat.com>
> > > Sent: Tuesday, October 9, 2012 5:01:39 PM
> > > Subject: Re: [Engine-devel] RFE: Netwrok Main Tab
> > > 
> > > On 10/09/2012 11:34 AM, Alona Kaplan wrote:
> > > > The wiki was updated with the final design.
> > > > http://wiki.ovirt.org/wiki/Feature/NetworkMainTab
> > > >
> > > > Thanks for the comments,
> > > > Alona.
> > > 
> > > Is the general sub-tab providing any information not available in
> > > the
> > > grid already?
> > > If not, lets drop it.
> 
> How complicated it will be to re-add it later?
> 
> There is no added information in this tab since right now there is
> not much to report, everything can easily fit into the columns. But
> thinking forward you may have other values and properties.
> 
> Just throwing some here not necessary for the near future so don't be
> alarmed, some may not/probably won't land in the general tab or the
> network main tab:
> - VM network / Storage / Migration / Management (*PS what is the
> current indication in this tab for management networks except for
> their names?)
> - Provider type - like external manager (Plug-in)/internal/etc (not
> sure it's a main tab item, but ... )
> - Mutually exclusive? Redundancy? other properties.
> - Last modified by ___ (It's a property that I would have loved to
> see on all objects instead of searching the event log)
> - Modification date
> - Global SLA Policy (for hierarchical SLA)
> 
> I think you got the drift
> And let's not forget 'Description' may not fully fit in it's column
> 
> I think it's worth to have it now then to add it later when the need
> compels it. But not feeling too strongly one way or the other.
> 
> 
> > > And while it's also consistent to show the clusters as the second
> > > (or
> > > now, after the above suggestion first) sub-tab, it's not an
> > > interesting
> > > tab. I suggest the default when clicking on a network is to show
> > > the
> > > VMs
> > > tab (so while the order of the tabs is not changed, the default
> > > shown
> > > is).
> 
> +1
> 
> > > Y.
> > > 
> > > 
> > > >
> > > > ----- Original Message -----
> > > >> From: "Simon Grinberg" <simon at redhat.com>
> > > >> To: "Alona Kaplan" <alkaplan at redhat.com>
> > > >> Cc: engine-devel at ovirt.org
> > > >> Sent: Tuesday, October 2, 2012 7:36:44 PM
> > > >> Subject: Re: [Engine-devel] RFE: Netwrok Main Tab
> > > >>
> > > >> Trying to sum up some of the suggestions ('coincidently'
> > > >> dropping
> > > >> those which I think a bit too much for first implementation
> > > >> :))
> > > >> and
> > > >> add some suggestions of my own
> > > >>
> > > >> 1. On the hosts subtab:
> > > >>     1.1 Have a radio button that will show either
> > > >>         1.1.1 All the hosts that this network is attached to
> > > >>         1.1.2 All the hosts where this network attached to the
> > > >>         cluster
> > > >>         but not to the host (Very important for non-required
> > > >>         where
> > > >>         the host status does not indicate something is
> > > >>         missing)
> > > >>     1.2 Have a remove button for 1.1.1, ManageNetworks button
> > > >>     for
> > > >>     1.1.2. Simple add will not do since you don't know where
> > > >>     to
> > > >>     add.
> > > >>
> > > >> 2. On the vms subtab
> > > >>     2.1 Have a radio button that will show either
> > > >>         2.1.1 All the vms that this network is attached to
> > > >>         2.1.2 All the vms where this network is not attached
> > > >>         to
> > > >>     2.2 Have a 'remove' button for 2.1.1, Have 'add' button
> > > >>     for
> > > >>     2.1.2
> > > >>     2.3 Allow multiple selection for both actions of 2.2
> > > >>     2.4 Add remove from all button.
> > > >>     2.5 I would not bother to show all the nics attached to
> > > >>     the
> > > >>     VM
> > > >>     from the same network, it's too rare. Just make sure there
> > > >>     is
> > > >>     no
> > > >>     exception if this does exist. So the columns should have
> > > >>     'nic'
> > > >>     as
> > > >>     the first and there should be only one VM per line. If
> > > >>     there
> > > >>     are
> > > >>     more then one nic per VM then just indicate 'multiple'
> > > >>
> > > >> 3. Templates subtab - same as VM, drop the expansion of the
> > > >> NICs
> > > >> list.
> > > >>
> > > >> 4. Clusters subtab
> > > >>     Allow assign to multiple clusters - same as the edit in
> > > >>     the
> > > >>     data
> > > >>     center tab (Just use the same dialogue)
> > > >>
> > > >> 5. Main: You have enough space then why not add the MTU
> > > >> column?
> > > >>
> > > >> 6. Queries for the sub tabs: For each needs the reverse query
> > > >> as
> > > >> well
> > > >> (Probably more important when adding new network)
> > > >>
> > > >>
> > > >> Oops, I think I mostly added and dropped (almost) nothing :)
> > > >>
> > > >> Regards,
> > > >> Simon
> > > >>   
> > > >>
> > > >> ----- Original Message -----
> > > >>> From: "Avi Tal" <atal at redhat.com>
> > > >>> To: "Yaniv Kaul" <ykaul at redhat.com>
> > > >>> Cc: engine-devel at ovirt.org
> > > >>> Sent: Monday, September 24, 2012 10:13:52 AM
> > > >>> Subject: Re: [Engine-devel] RFE: Netwrok Main Tab
> > > >>>
> > > >>>
> > > >>>
> > > >>> ----- Original Message -----
> > > >>>> From: "Yaniv Kaul" <ykaul at redhat.com>
> > > >>>> To: "Moti Asayag" <masayag at redhat.com>
> > > >>>> Cc: engine-devel at ovirt.org
> > > >>>> Sent: Sunday, September 23, 2012 6:16:47 PM
> > > >>>> Subject: Re: [Engine-devel] RFE: Netwrok Main Tab
> > > >>>>
> > > >>>> On 09/23/2012 06:12 PM, Moti Asayag wrote:
> > > >>>>> On 09/23/2012 05:01 PM, Yaniv Kaul wrote:
> > > >>>>>> On 09/23/2012 04:55 PM, Alona Kaplan wrote:
> > > >>>>>>> ----- Original Message -----
> > > >>>>>>>> From: "Avi Tal" <atal at redhat.com>
> > > >>>>>>>> To: "Alona Kaplan" <alkaplan at redhat.com>
> > > >>>>>>>> Cc: engine-devel at ovirt.org
> > > >>>>>>>> Sent: Sunday, September 23, 2012 4:17:26 PM
> > > >>>>>>>> Subject: Re: [Engine-devel] RFE: Netwrok Main Tab
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> ----- Original Message -----
> > > >>>>>>>>> From: "Alona Kaplan" <alkaplan at redhat.com>
> > > >>>>>>>>> To: "Avi Tal" <atal at redhat.com>
> > > >>>>>>>>> Cc: engine-devel at ovirt.org
> > > >>>>>>>>> Sent: Sunday, September 23, 2012 1:31:32 PM
> > > >>>>>>>>> Subject: Re: [Engine-devel] RFE: Netwrok Main Tab
> > > >>>>>>>>>
> > > >>>>>>>>> 1. What actions do you suggest to add?
> > > >>>>>>>> Add, Edit and remove actions of each component.
> > > >>>>>>>>
> > > >>>>>>> Host:
> > > >>>>>>> Add- What will add action on Networks->Hosts sub tab do?
> > > >>>>>>> Choose
> > > >>>>>>> an
> > > >>>>>>> existing host and attach the network to one of its nics?
> > > >>>>>>> How will it work? after choosing the host you will open
> > > >>>>>>> setupNetworks
> > > >>>>>>> window and just enable dragging of the selected network
> > > >>>>>>> (in
> > > >>>>>>> the
> > > >>>>>>> main
> > > >>>>>>> tab) to a nic? I think it is too much.
> > > >>>>>>>
> > > >>>>>>> Edit- same as add.
> > > >>>>>>>
> > > >>>>>>> Remove- What is the meaning of Remove host in network's
> > > >>>>>>> context?
> > > >>>>>>> The
> > > >>>>>>> network will be detached from the host? I think it is
> > > >>>>>>> confusing.
> > > >>>>>>>
> > > >>>>>>> Vm/Template:
> > > >>>>>>> Add: What will it do? You will choose a vm and then add a
> > > >>>>>>> vnic
> > > >>>>>>> to
> > > >>>>>>> the
> > > >>>>>>> vm? Where will you see the vnic details?
> > > >>>>>>> Edit: Same as add.
> > > >>>>>>> Remove: You will remove all the vnics that use the
> > > >>>>>>> selected
> > > >>>>>>> network
> > > >>>>>>> from the vm? Or do you mean to add a remove per vnic?
> > > >>>>>> For all the above: yes.
> > > >>>>>> We can certainly work on the small details, but having a
> > > >>>>>> main
> > > >>>>>> tab
> > > >>>>>> with
> > > >>>>>> little to no action whatsoever is kinda disappointing.
> > > >>>>> IMO adding 'assign' action in the main tab might be handy
> > > >>>>> in
> > > >>>>> order
> > > >>>>> to
> > > >>>>> assign a single network in a single dialog to several
> > > >>>>> clusters.
> > > >>>>>
> > > >>>>> However It is not clear to me how Add/Edit for a VM in a
> > > >>>>> sub-tab
> > > >>>>> should
> > > >>>>> look like. The VM should have a list of interfaces
> > > >>>>> (represented
> > > >>>>> as
> > > >>>>> sub
> > > >>>>> collection/tree).
> > > >>>> I was thinking more of right-click on the network, selecting
> > > >>>> 'Add
> > > >>>> to
> > > >>>> VM'
> > > >>>> and then selecting single/mutliple VMs from a dialog with
> > > >>>> all
> > > >>>> the
> > > >>>> VMs
> > > >>>> (yes, filtered via search).
> > > >>>> Y.
> > > >>>>
> > > >>> +1
> > > >>>
> > > >>>>> What will be the meaning of 'Add' in that context? Since
> > > >>>>> the
> > > >>>>> VM
> > > >>>>> already
> > > >>>>> have a vNIC attached to that network. If adding another
> > > >>>>> once,
> > > >>>>> it
> > > >>>>> should
> > > >>>>> be enabled on the record representing the VM itself which
> > > >>>>> will
> > > >>>>> confuse
> > > >>>>> the user.
> > > >>>>> Same goes for 'Edit' of a VM interface under a context of a
> > > >>>>> specific
> > > >>>>> network: in the current 'Edit VM Interface' you can change
> > > >>>>> the
> > > >>>>> network.
> > > >>>>> Should the same dialog be used here as well?
> > > >>>>>
> > > >>>>> The 'Remove' option is the clearer action on this context.
> > > >>>>>
> > > >>>>>
> > > >>>>>> (example of 'small details' - yes, when clicking remove
> > > >>>>>> for
> > > >>>>>> a
> > > >>>>>> VM/template - it will remove all vNICs that use that
> > > >>>>>> network
> > > >>>>>> from
> > > >>>>>> the
> > > >>>>>> VM. A VM with more than one vNIC on the same network is
> > > >>>>>> not
> > > >>>>>> the
> > > >>>>>> common
> > > >>>>>> case anyway, and if you want to remove just a single vNIC,
> > > >>>>>> go
> > > >>>>>> to
> > > >>>>>> the
> > > >>>>>> VM). I think we can also live with Add/Remove only, and
> > > >>>>>> 'defer'
> > > >>>>>> the edit
> > > >>>>>> actions to the respectable objects (host/vm/template) edit
> > > >>>>>> dialog
> > > >>>>>> boxes
> > > >>>>>> that originates from their own main tab.
> > > >>>>>>
> > > >>>>>> Y.
> > > >>>>>>
> > > >>>>>>>>> 2. I don't understand your suggestion. You mean add
> > > >>>>>>>>> SetupNetworks
> > > >>>>>>>>> to
> > > >>>>>>>>> the Networks main tab?
> > > >>>>>>>> No.
> > > >>>>>>>> Just Thinking of a nice display which will present
> > > >>>>>>>> logical
> > > >>>>>>>> network
> > > >>>>>>>> and his connected host/vm configuration instead of
> > > >>>>>>>> passing
> > > >>>>>>>> through
> > > >>>>>>>> dub-tabs
> > > >>>>>>>> I should give it a deeper thought.
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>>> ----- Original Message -----
> > > >>>>>>>>>> From: "Avi Tal" <atal at redhat.com>
> > > >>>>>>>>>> To: "Alona Kaplan" <alkaplan at redhat.com>
> > > >>>>>>>>>> Cc: engine-devel at ovirt.org
> > > >>>>>>>>>> Sent: Thursday, September 20, 2012 6:58:05 PM
> > > >>>>>>>>>> Subject: Re: [Engine-devel] RFE: Netwrok Main Tab
> > > >>>>>>>>>>
> > > >>>>>>>>>> 1. Why not having Actions for Hosts, Vms and Templates
> > > >>>>>>>>>> ?
> > > >>>>>>>>>> I believe we should have those actions instead of
> > > >>>>>>>>>> making
> > > >>>>>>>>>> the
> > > >>>>>>>>>> user
> > > >>>>>>>>>> browse between 'network -> vms -> network (sub tab)'
> > > >>>>>>>>>> just
> > > >>>>>>>>>> in
> > > >>>>>>>>>> order
> > > >>>>>>>>>> to update VM's network.
> > > >>>>>>>>>>
> > > >>>>>>>>>> 2. Why having such a big window which most of the time
> > > >>>>>>>>>> will
> > > >>>>>>>>>> be
> > > >>>>>>>>>> empty?
> > > >>>>>>>>>>       How many logical network would be existed in the
> > > >>>>>>>>>>       system?
> > > >>>>>>>>>>       My suggestion is to go for more graphical window
> > > >>>>>>>>>>       which
> > > >>>>>>>>>>       will
> > > >>>>>>>>>>       present:
> > > >>>>>>>>>>       A. logical networks
> > > >>>>>>>>>>       B. Multiple networks with the host
> > > >>>>>>>>>>       configurations
> > > >>>>>>>>>>       at
> > > >>>>>>>>>>       the
> > > >>>>>>>>>>       same
> > > >>>>>>>>>>       window: very important because most of the
> > > >>>>>>>>>>       System
> > > >>>>>>>>>>       admins
> > > >>>>>>>>>>       would
> > > >>>>>>>>>>       like to have a bigger picture of the entire
> > > >>>>>>>>>>       network
> > > >>>>>>>>>>       configuration
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>> ----- Original Message -----
> > > >>>>>>>>>> From: "Alona Kaplan" <alkaplan at redhat.com>
> > > >>>>>>>>>> To: engine-devel at ovirt.org
> > > >>>>>>>>>> Sent: Thursday, September 20, 2012 1:50:15 PM
> > > >>>>>>>>>> Subject: [Engine-devel] RFE: Netwrok Main Tab
> > > >>>>>>>>>>
> > > >>>>>>>>>> Hi all,
> > > >>>>>>>>>>
> > > >>>>>>>>>> Please review the wiki and add your comments.
> > > >>>>>>>>>>
> > > >>>>>>>>>> http://wiki.ovirt.org/wiki/Feature/NetworkMainTab
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>> RFE:
> > > >>>>>>>>>> https://bugzilla.redhat.com/858742
> > > >>>>>>>>>>
> > > >>>>>>>>>> Thanks,
> > > >>>>>>>>>> Alona.
> > > >>>>>>>>>> _______________________________________________
> > > >>>>>>>>>> Engine-devel mailing list
> > > >>>>>>>>>> Engine-devel at ovirt.org
> > > >>>>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > >>>>>>>>>>
> > > >>>>>>> _______________________________________________
> > > >>>>>>> Engine-devel mailing list
> > > >>>>>>> Engine-devel at ovirt.org
> > > >>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > >>>>>> _______________________________________________
> > > >>>>>> Engine-devel mailing list
> > > >>>>>> Engine-devel at ovirt.org
> > > >>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > >>>> _______________________________________________
> > > >>>> Engine-devel mailing list
> > > >>>> Engine-devel at ovirt.org
> > > >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > >>>>
> > > >>> _______________________________________________
> > > >>> Engine-devel mailing list
> > > >>> Engine-devel at ovirt.org
> > > >>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > >>>
> > > 
> > > 
> > 
> 


From simon at redhat.com  Wed Oct 10 12:24:13 2012
From: simon at redhat.com (Simon Grinberg)
Date: Wed, 10 Oct 2012 08:24:13 -0400 (EDT)
Subject: [Engine-devel] RFE: Netwrok Main Tab
In-Reply-To: <795625706.10763572.1349871130460.JavaMail.root@redhat.com>
Message-ID: <2146661461.9901512.1349871853125.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Alona Kaplan" <alkaplan at redhat.com>
> To: "Simon Grinberg" <simon at redhat.com>
> Cc: engine-devel at ovirt.org, "Muli Salem" <msalem at redhat.com>, "Moti Asayag" <masayag at redhat.com>, "Avi Tal"
> <atal at redhat.com>, "Yaniv Kaul" <ykaul at redhat.com>
> Sent: Wednesday, October 10, 2012 2:12:10 PM
> Subject: Re: [Engine-devel] RFE: Netwrok Main Tab
> 
> So the conclusion is to leave the General tab but make the vm tab the
> default one?

Depends on other inputs as well, currently you have one that thinks is should be removed and one the thinks it should remain for future values :)

> 
> There is no indication for the management networks except of the
> name. The name can be bold or we can add extra column to indicate
> it.

+1 for another column, remember that in the future we should probably allow different names for this network.
In addition this tab is common to all the DC, meaning more then one of these networks. Hopefully when you'll get sort by column this should be one of the attributes to sort by. 


> 
> ----- Original Message -----
> > From: "Simon Grinberg" <simon at redhat.com>
> > To: "Alona Kaplan" <alkaplan at redhat.com>
> > Cc: engine-devel at ovirt.org, "Muli Salem" <msalem at redhat.com>, "Moti
> > Asayag" <masayag at redhat.com>, "Avi Tal"
> > <atal at redhat.com>, "Yaniv Kaul" <ykaul at redhat.com>
> > Sent: Wednesday, October 10, 2012 1:40:18 PM
> > Subject: Re: [Engine-devel] RFE: Netwrok Main Tab
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Alona Kaplan" <alkaplan at redhat.com>
> > > To: "Simon Grinberg" <sgrinber at redhat.com>
> > > Cc: engine-devel at ovirt.org, "Muli Salem" <msalem at redhat.com>,
> > > "Moti
> > > Asayag" <masayag at redhat.com>, "Avi Tal"
> > > <atal at redhat.com>, "Yaniv Kaul" <ykaul at redhat.com>
> > > Sent: Wednesday, October 10, 2012 10:39:50 AM
> > > Subject: Re: [Engine-devel] RFE: Netwrok Main Tab
> > > 
> > > I agree.
> > > 
> > > Simon, what do you think?
> > > 
> > > ----- Original Message -----
> > > > From: "Yaniv Kaul" <ykaul at redhat.com>
> > > > To: "Alona Kaplan" <alkaplan at redhat.com>
> > > > Cc: engine-devel at ovirt.org, "Muli Salem" <msalem at redhat.com>,
> > > > "Moti
> > > > Asayag" <masayag at redhat.com>, "Avi Tal"
> > > > <atal at redhat.com>, "Simon Grinberg" <sgrinber at redhat.com>
> > > > Sent: Tuesday, October 9, 2012 5:01:39 PM
> > > > Subject: Re: [Engine-devel] RFE: Netwrok Main Tab
> > > > 
> > > > On 10/09/2012 11:34 AM, Alona Kaplan wrote:
> > > > > The wiki was updated with the final design.
> > > > > http://wiki.ovirt.org/wiki/Feature/NetworkMainTab
> > > > >
> > > > > Thanks for the comments,
> > > > > Alona.
> > > > 
> > > > Is the general sub-tab providing any information not available
> > > > in
> > > > the
> > > > grid already?
> > > > If not, lets drop it.
> > 
> > How complicated it will be to re-add it later?
> > 
> > There is no added information in this tab since right now there is
> > not much to report, everything can easily fit into the columns. But
> > thinking forward you may have other values and properties.
> > 
> > Just throwing some here not necessary for the near future so don't
> > be
> > alarmed, some may not/probably won't land in the general tab or the
> > network main tab:
> > - VM network / Storage / Migration / Management (*PS what is the
> > current indication in this tab for management networks except for
> > their names?)
> > - Provider type - like external manager (Plug-in)/internal/etc (not
> > sure it's a main tab item, but ... )
> > - Mutually exclusive? Redundancy? other properties.
> > - Last modified by ___ (It's a property that I would have loved to
> > see on all objects instead of searching the event log)
> > - Modification date
> > - Global SLA Policy (for hierarchical SLA)
> > 
> > I think you got the drift
> > And let's not forget 'Description' may not fully fit in it's column
> > 
> > I think it's worth to have it now then to add it later when the
> > need
> > compels it. But not feeling too strongly one way or the other.
> > 
> > 
> > > > And while it's also consistent to show the clusters as the
> > > > second
> > > > (or
> > > > now, after the above suggestion first) sub-tab, it's not an
> > > > interesting
> > > > tab. I suggest the default when clicking on a network is to
> > > > show
> > > > the
> > > > VMs
> > > > tab (so while the order of the tabs is not changed, the default
> > > > shown
> > > > is).
> > 
> > +1
> > 
> > > > Y.
> > > > 
> > > > 
> > > > >
> > > > > ----- Original Message -----
> > > > >> From: "Simon Grinberg" <simon at redhat.com>
> > > > >> To: "Alona Kaplan" <alkaplan at redhat.com>
> > > > >> Cc: engine-devel at ovirt.org
> > > > >> Sent: Tuesday, October 2, 2012 7:36:44 PM
> > > > >> Subject: Re: [Engine-devel] RFE: Netwrok Main Tab
> > > > >>
> > > > >> Trying to sum up some of the suggestions ('coincidently'
> > > > >> dropping
> > > > >> those which I think a bit too much for first implementation
> > > > >> :))
> > > > >> and
> > > > >> add some suggestions of my own
> > > > >>
> > > > >> 1. On the hosts subtab:
> > > > >>     1.1 Have a radio button that will show either
> > > > >>         1.1.1 All the hosts that this network is attached to
> > > > >>         1.1.2 All the hosts where this network attached to
> > > > >>         the
> > > > >>         cluster
> > > > >>         but not to the host (Very important for non-required
> > > > >>         where
> > > > >>         the host status does not indicate something is
> > > > >>         missing)
> > > > >>     1.2 Have a remove button for 1.1.1, ManageNetworks
> > > > >>     button
> > > > >>     for
> > > > >>     1.1.2. Simple add will not do since you don't know where
> > > > >>     to
> > > > >>     add.
> > > > >>
> > > > >> 2. On the vms subtab
> > > > >>     2.1 Have a radio button that will show either
> > > > >>         2.1.1 All the vms that this network is attached to
> > > > >>         2.1.2 All the vms where this network is not attached
> > > > >>         to
> > > > >>     2.2 Have a 'remove' button for 2.1.1, Have 'add' button
> > > > >>     for
> > > > >>     2.1.2
> > > > >>     2.3 Allow multiple selection for both actions of 2.2
> > > > >>     2.4 Add remove from all button.
> > > > >>     2.5 I would not bother to show all the nics attached to
> > > > >>     the
> > > > >>     VM
> > > > >>     from the same network, it's too rare. Just make sure
> > > > >>     there
> > > > >>     is
> > > > >>     no
> > > > >>     exception if this does exist. So the columns should have
> > > > >>     'nic'
> > > > >>     as
> > > > >>     the first and there should be only one VM per line. If
> > > > >>     there
> > > > >>     are
> > > > >>     more then one nic per VM then just indicate 'multiple'
> > > > >>
> > > > >> 3. Templates subtab - same as VM, drop the expansion of the
> > > > >> NICs
> > > > >> list.
> > > > >>
> > > > >> 4. Clusters subtab
> > > > >>     Allow assign to multiple clusters - same as the edit in
> > > > >>     the
> > > > >>     data
> > > > >>     center tab (Just use the same dialogue)
> > > > >>
> > > > >> 5. Main: You have enough space then why not add the MTU
> > > > >> column?
> > > > >>
> > > > >> 6. Queries for the sub tabs: For each needs the reverse
> > > > >> query
> > > > >> as
> > > > >> well
> > > > >> (Probably more important when adding new network)
> > > > >>
> > > > >>
> > > > >> Oops, I think I mostly added and dropped (almost) nothing :)
> > > > >>
> > > > >> Regards,
> > > > >> Simon
> > > > >>   
> > > > >>
> > > > >> ----- Original Message -----
> > > > >>> From: "Avi Tal" <atal at redhat.com>
> > > > >>> To: "Yaniv Kaul" <ykaul at redhat.com>
> > > > >>> Cc: engine-devel at ovirt.org
> > > > >>> Sent: Monday, September 24, 2012 10:13:52 AM
> > > > >>> Subject: Re: [Engine-devel] RFE: Netwrok Main Tab
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>> ----- Original Message -----
> > > > >>>> From: "Yaniv Kaul" <ykaul at redhat.com>
> > > > >>>> To: "Moti Asayag" <masayag at redhat.com>
> > > > >>>> Cc: engine-devel at ovirt.org
> > > > >>>> Sent: Sunday, September 23, 2012 6:16:47 PM
> > > > >>>> Subject: Re: [Engine-devel] RFE: Netwrok Main Tab
> > > > >>>>
> > > > >>>> On 09/23/2012 06:12 PM, Moti Asayag wrote:
> > > > >>>>> On 09/23/2012 05:01 PM, Yaniv Kaul wrote:
> > > > >>>>>> On 09/23/2012 04:55 PM, Alona Kaplan wrote:
> > > > >>>>>>> ----- Original Message -----
> > > > >>>>>>>> From: "Avi Tal" <atal at redhat.com>
> > > > >>>>>>>> To: "Alona Kaplan" <alkaplan at redhat.com>
> > > > >>>>>>>> Cc: engine-devel at ovirt.org
> > > > >>>>>>>> Sent: Sunday, September 23, 2012 4:17:26 PM
> > > > >>>>>>>> Subject: Re: [Engine-devel] RFE: Netwrok Main Tab
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>> ----- Original Message -----
> > > > >>>>>>>>> From: "Alona Kaplan" <alkaplan at redhat.com>
> > > > >>>>>>>>> To: "Avi Tal" <atal at redhat.com>
> > > > >>>>>>>>> Cc: engine-devel at ovirt.org
> > > > >>>>>>>>> Sent: Sunday, September 23, 2012 1:31:32 PM
> > > > >>>>>>>>> Subject: Re: [Engine-devel] RFE: Netwrok Main Tab
> > > > >>>>>>>>>
> > > > >>>>>>>>> 1. What actions do you suggest to add?
> > > > >>>>>>>> Add, Edit and remove actions of each component.
> > > > >>>>>>>>
> > > > >>>>>>> Host:
> > > > >>>>>>> Add- What will add action on Networks->Hosts sub tab
> > > > >>>>>>> do?
> > > > >>>>>>> Choose
> > > > >>>>>>> an
> > > > >>>>>>> existing host and attach the network to one of its
> > > > >>>>>>> nics?
> > > > >>>>>>> How will it work? after choosing the host you will open
> > > > >>>>>>> setupNetworks
> > > > >>>>>>> window and just enable dragging of the selected network
> > > > >>>>>>> (in
> > > > >>>>>>> the
> > > > >>>>>>> main
> > > > >>>>>>> tab) to a nic? I think it is too much.
> > > > >>>>>>>
> > > > >>>>>>> Edit- same as add.
> > > > >>>>>>>
> > > > >>>>>>> Remove- What is the meaning of Remove host in network's
> > > > >>>>>>> context?
> > > > >>>>>>> The
> > > > >>>>>>> network will be detached from the host? I think it is
> > > > >>>>>>> confusing.
> > > > >>>>>>>
> > > > >>>>>>> Vm/Template:
> > > > >>>>>>> Add: What will it do? You will choose a vm and then add
> > > > >>>>>>> a
> > > > >>>>>>> vnic
> > > > >>>>>>> to
> > > > >>>>>>> the
> > > > >>>>>>> vm? Where will you see the vnic details?
> > > > >>>>>>> Edit: Same as add.
> > > > >>>>>>> Remove: You will remove all the vnics that use the
> > > > >>>>>>> selected
> > > > >>>>>>> network
> > > > >>>>>>> from the vm? Or do you mean to add a remove per vnic?
> > > > >>>>>> For all the above: yes.
> > > > >>>>>> We can certainly work on the small details, but having a
> > > > >>>>>> main
> > > > >>>>>> tab
> > > > >>>>>> with
> > > > >>>>>> little to no action whatsoever is kinda disappointing.
> > > > >>>>> IMO adding 'assign' action in the main tab might be handy
> > > > >>>>> in
> > > > >>>>> order
> > > > >>>>> to
> > > > >>>>> assign a single network in a single dialog to several
> > > > >>>>> clusters.
> > > > >>>>>
> > > > >>>>> However It is not clear to me how Add/Edit for a VM in a
> > > > >>>>> sub-tab
> > > > >>>>> should
> > > > >>>>> look like. The VM should have a list of interfaces
> > > > >>>>> (represented
> > > > >>>>> as
> > > > >>>>> sub
> > > > >>>>> collection/tree).
> > > > >>>> I was thinking more of right-click on the network,
> > > > >>>> selecting
> > > > >>>> 'Add
> > > > >>>> to
> > > > >>>> VM'
> > > > >>>> and then selecting single/mutliple VMs from a dialog with
> > > > >>>> all
> > > > >>>> the
> > > > >>>> VMs
> > > > >>>> (yes, filtered via search).
> > > > >>>> Y.
> > > > >>>>
> > > > >>> +1
> > > > >>>
> > > > >>>>> What will be the meaning of 'Add' in that context? Since
> > > > >>>>> the
> > > > >>>>> VM
> > > > >>>>> already
> > > > >>>>> have a vNIC attached to that network. If adding another
> > > > >>>>> once,
> > > > >>>>> it
> > > > >>>>> should
> > > > >>>>> be enabled on the record representing the VM itself which
> > > > >>>>> will
> > > > >>>>> confuse
> > > > >>>>> the user.
> > > > >>>>> Same goes for 'Edit' of a VM interface under a context of
> > > > >>>>> a
> > > > >>>>> specific
> > > > >>>>> network: in the current 'Edit VM Interface' you can
> > > > >>>>> change
> > > > >>>>> the
> > > > >>>>> network.
> > > > >>>>> Should the same dialog be used here as well?
> > > > >>>>>
> > > > >>>>> The 'Remove' option is the clearer action on this
> > > > >>>>> context.
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>> (example of 'small details' - yes, when clicking remove
> > > > >>>>>> for
> > > > >>>>>> a
> > > > >>>>>> VM/template - it will remove all vNICs that use that
> > > > >>>>>> network
> > > > >>>>>> from
> > > > >>>>>> the
> > > > >>>>>> VM. A VM with more than one vNIC on the same network is
> > > > >>>>>> not
> > > > >>>>>> the
> > > > >>>>>> common
> > > > >>>>>> case anyway, and if you want to remove just a single
> > > > >>>>>> vNIC,
> > > > >>>>>> go
> > > > >>>>>> to
> > > > >>>>>> the
> > > > >>>>>> VM). I think we can also live with Add/Remove only, and
> > > > >>>>>> 'defer'
> > > > >>>>>> the edit
> > > > >>>>>> actions to the respectable objects (host/vm/template)
> > > > >>>>>> edit
> > > > >>>>>> dialog
> > > > >>>>>> boxes
> > > > >>>>>> that originates from their own main tab.
> > > > >>>>>>
> > > > >>>>>> Y.
> > > > >>>>>>
> > > > >>>>>>>>> 2. I don't understand your suggestion. You mean add
> > > > >>>>>>>>> SetupNetworks
> > > > >>>>>>>>> to
> > > > >>>>>>>>> the Networks main tab?
> > > > >>>>>>>> No.
> > > > >>>>>>>> Just Thinking of a nice display which will present
> > > > >>>>>>>> logical
> > > > >>>>>>>> network
> > > > >>>>>>>> and his connected host/vm configuration instead of
> > > > >>>>>>>> passing
> > > > >>>>>>>> through
> > > > >>>>>>>> dub-tabs
> > > > >>>>>>>> I should give it a deeper thought.
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>>> ----- Original Message -----
> > > > >>>>>>>>>> From: "Avi Tal" <atal at redhat.com>
> > > > >>>>>>>>>> To: "Alona Kaplan" <alkaplan at redhat.com>
> > > > >>>>>>>>>> Cc: engine-devel at ovirt.org
> > > > >>>>>>>>>> Sent: Thursday, September 20, 2012 6:58:05 PM
> > > > >>>>>>>>>> Subject: Re: [Engine-devel] RFE: Netwrok Main Tab
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> 1. Why not having Actions for Hosts, Vms and
> > > > >>>>>>>>>> Templates
> > > > >>>>>>>>>> ?
> > > > >>>>>>>>>> I believe we should have those actions instead of
> > > > >>>>>>>>>> making
> > > > >>>>>>>>>> the
> > > > >>>>>>>>>> user
> > > > >>>>>>>>>> browse between 'network -> vms -> network (sub tab)'
> > > > >>>>>>>>>> just
> > > > >>>>>>>>>> in
> > > > >>>>>>>>>> order
> > > > >>>>>>>>>> to update VM's network.
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> 2. Why having such a big window which most of the
> > > > >>>>>>>>>> time
> > > > >>>>>>>>>> will
> > > > >>>>>>>>>> be
> > > > >>>>>>>>>> empty?
> > > > >>>>>>>>>>       How many logical network would be existed in
> > > > >>>>>>>>>>       the
> > > > >>>>>>>>>>       system?
> > > > >>>>>>>>>>       My suggestion is to go for more graphical
> > > > >>>>>>>>>>       window
> > > > >>>>>>>>>>       which
> > > > >>>>>>>>>>       will
> > > > >>>>>>>>>>       present:
> > > > >>>>>>>>>>       A. logical networks
> > > > >>>>>>>>>>       B. Multiple networks with the host
> > > > >>>>>>>>>>       configurations
> > > > >>>>>>>>>>       at
> > > > >>>>>>>>>>       the
> > > > >>>>>>>>>>       same
> > > > >>>>>>>>>>       window: very important because most of the
> > > > >>>>>>>>>>       System
> > > > >>>>>>>>>>       admins
> > > > >>>>>>>>>>       would
> > > > >>>>>>>>>>       like to have a bigger picture of the entire
> > > > >>>>>>>>>>       network
> > > > >>>>>>>>>>       configuration
> > > > >>>>>>>>>>
> > > > >>>>>>>>>>
> > > > >>>>>>>>>>
> > > > >>>>>>>>>>
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> ----- Original Message -----
> > > > >>>>>>>>>> From: "Alona Kaplan" <alkaplan at redhat.com>
> > > > >>>>>>>>>> To: engine-devel at ovirt.org
> > > > >>>>>>>>>> Sent: Thursday, September 20, 2012 1:50:15 PM
> > > > >>>>>>>>>> Subject: [Engine-devel] RFE: Netwrok Main Tab
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> Hi all,
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> Please review the wiki and add your comments.
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> http://wiki.ovirt.org/wiki/Feature/NetworkMainTab
> > > > >>>>>>>>>>
> > > > >>>>>>>>>>
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> RFE:
> > > > >>>>>>>>>> https://bugzilla.redhat.com/858742
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> Thanks,
> > > > >>>>>>>>>> Alona.
> > > > >>>>>>>>>> _______________________________________________
> > > > >>>>>>>>>> Engine-devel mailing list
> > > > >>>>>>>>>> Engine-devel at ovirt.org
> > > > >>>>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > >>>>>>>>>>
> > > > >>>>>>> _______________________________________________
> > > > >>>>>>> Engine-devel mailing list
> > > > >>>>>>> Engine-devel at ovirt.org
> > > > >>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > >>>>>> _______________________________________________
> > > > >>>>>> Engine-devel mailing list
> > > > >>>>>> Engine-devel at ovirt.org
> > > > >>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > >>>> _______________________________________________
> > > > >>>> Engine-devel mailing list
> > > > >>>> Engine-devel at ovirt.org
> > > > >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > >>>>
> > > > >>> _______________________________________________
> > > > >>> Engine-devel mailing list
> > > > >>> Engine-devel at ovirt.org
> > > > >>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > >>>
> > > > 
> > > > 
> > > 
> > 
> 


From dlaor at redhat.com  Wed Oct 10 12:36:11 2012
From: dlaor at redhat.com (Dor Laor)
Date: Wed, 10 Oct 2012 14:36:11 +0200
Subject: [Engine-devel] [vdsm] Mom Balloon policy issue
In-Reply-To: <414657630.10706381.1349860992830.JavaMail.root@redhat.com>
References: <414657630.10706381.1349860992830.JavaMail.root@redhat.com>
Message-ID: <50756BBB.4030506@redhat.com>

On 10/10/2012 11:23 AM, Noam Slomianko wrote:
> Regarding qemu-kvm memory allocation behaviour, this is the clearest explanation I found:
>
> "Unless using explicit hugepages for the guest, KVM will
> *not* initially allocate all RAM from the host OS. Each
> page of RAM is only allocated when the guest OS touches
> that page. So if you set memory=8G and currentMemory=4G,
> although you might expect resident usage of KVM on the
> host to be 4 G, it can in fact be pretty much any value
> between 0 and 4 GB depending on whether the guest OS
> has touched the memory pages, or as much as 8 GB if the
> guest OS has no balloon driver and touches all memory
> immediately."[1]

A simpler explanation is that we use demand paging with allocating the 
guest RAM and thus we don't instantiate any page prior to its usage by 
the guest. It's the same with huge pages as long as prealloc isn't called.

>
> And as far as I've seen it behave the same after the guest is ballooned and then deflated.
>
> Conclusion, the time in which the guest is allocated the resident memory is not deterministic and dependent on use and OS
> For example Windows7 uses all available memory as cache while fedora does not.

(not cache but zero the pages).

> So an inactive guest running windows7 will consume all possible resident memory right away while an inactive guest running fedora might never grow in memory size.

It takes time for win7 to touch all the pages (during its boot) and to 
KVM to allocate it so it's not instantaneous.

One can measure exactly the current size of qemu's rss so MOM can be 
aware of it.

>
> [1] http://www.redhat.com/archives/virt-tools-list/2011-January/msg00001.html
>
> ------------------
> Noam Slomianko
> Red Hat Enterprise Virtualization, SLA team
>
> ----- Original Message -----
> From: "Adam Litke" <agl at us.ibm.com>
> To: "Noam Slomianko" <nslomian at redhat.com>
> Cc: "Doron Fediuck" <dfediuck at redhat.com>, vdsm-devel at lists.fedorahosted.org, engine-devel at ovirt.org
> Sent: Tuesday, October 9, 2012 8:06:02 PM
> Subject: Re: Mom Balloon policy issue
>
> Thanks for writing this.  Some thoughts inline, below.  Also, cc'ing some lists
> in case other folks want to participate in the discussion.
>
> On Tue, Oct 09, 2012 at 01:12:30PM -0400, Noam Slomianko wrote:
>> Greetings,
>>
>> I've fiddled around with ballooning and wanted to raise a question for debate.
>>
>> Currently as long as the host is under memory pressure, MOM will try and reclaim back memory from all guests with more free memory then a given threshold.
>>
>> Main issue: Guest allocated memory is not the same as the resident (physical) memory used by qemu.
>> This means that when memory is reclaimed back (the balloon is inflated) we might not get as much memory as planed back (or non at all).
>>
>>   *Example1 no memory is reclaimed back:
>>      name | allocated memory | used by the vm | resident memory used in the host by qemu
>>      Vm1  |       4G         |       4G,      |                4G
>>      Vm2  |       4G         |       1G       |                1G
>>   - MOM will inflate the balloon in vm2 (as vm has no free memory) and will gain no memory
>
> One thing to keep in mind is that VMs having less host RSS than their memory
> allocation is a temporary condition.  All VMs will eventually consume their full
> allocation if allowed to run.  I'd be curious to know how long this process
> takes in general.
>
> We might be able to handle this case by refusing to inflate the balloon if:
>      (VM free memory - planned balloon inflation) > host RSS
>
>
>>   *Example1 memory is reclaimed partially:
>>      name | allocated memory | used by the vm | resident memory used in the host by qemu
>>      Vm1  |       4G         |       4G,      |                4G
>>      Vm2  |       4G         |       1G       |                1G
>>      Vm3  |       4G         |       1G       |                4G
>>   - MOM will inflate the balloon in vm2 and vm3 slowly gaining only from vm3
>
> The above rule extension may help here too.
>
>> this behaviour might in the cause us to:
>>   * spend time reclaiming memory from many guests when we can reclaim only from a subgroup
>>   * be under the impression that we have more potential memory to reclaim when we do
>>   * bring inactive VMs dangerously low as they are constantly reclaimed (I've had guests crashing from kernel out of memory)
>>
>>
>> To address this I suggest that we collect guest memory stats from libvirt as well, so we have the option to use them in our calculations.
>> This can be achieved with the command "virsh dommemstat <domain>" which returns
>>      actual 3915372 (allocated)
>>      rss 2141580 (resident memory used by qemu)
>
> I would suggest adding these two fields to the VmStats that are collected by
> vdsm.  Then, to try it out, add the fields to the GuestMemory Collector.  (Note:
> MOM does have a collector that gathers RSS for VMs.  It's called GuestQemuProc).
> You can then extend the Balloon policy to add a snippet to check if the proposed
> balloon adjustment should be carried out.  You could add the logic to the
> change_big_enough function.
>
>> additional topic:
>>   * should we include per guest config (for example a hard minimum memory cap, this vm cannot run effectively with less then 1G memory)
>
> Yes.  This is probably something we want to do.  There is a whole topic around
> VM tagging that we should consider.  In the future we will want to be able to do
> many different things in policy based on a VMs tag.  For example, some VMs may
> be completely exempt from ballooning.  Others may have a minimum limit.
>
> I want to avoid passing in the raw guest configuration because MOM needs to work
> with direct libvirt vms and with ovirt/vdsm vms.  Therefore, we want to think
> carefully about the abstractions we use when presenting VM properties to MOM.
>



From ilvovsky at redhat.com  Wed Oct 10 14:47:28 2012
From: ilvovsky at redhat.com (Igor Lvovsky)
Date: Wed, 10 Oct 2012 10:47:28 -0400 (EDT)
Subject: [Engine-devel] Network related hooks in vdsm
In-Reply-To: <2144260814.8654397.1349869142382.JavaMail.root@redhat.com>
Message-ID: <205895767.8750976.1349880448089.JavaMail.root@redhat.com>

  Hi everyone,
As you know vdsm has hooks mechanism and we already support dozen of hooks for different needs.
Now it's a network's time.
We would like to get your comments regarding our proposition for network related hooks.

In general we are planning to prepare framework for future support of bunch network related hooks.
Some of them already proposed by Itzik Brown [1] and Dan Yasny [2].

Below you can find the additional hooks list that we propose:

Note: In the first stage we can implement these hooks without any parameters, just to provide an entry point
 for simple hooks.

Networks manipulation:
- before_add_network(conf={}, customProperty={})
- after_add_network(conf={}, customProperty={})
- before_del_network(conf={}, customProperty={})
- after_del_network(conf={}, customProperty={})
- before_edit_network(conf={}, customProperty={})
- after_edit_network(conf={}, customProperty={})
- TBD

Bondings manipulations:
- before_add_bond(conf={}, customProperty={})
- after_add_bond(conf={}, customProperty={})
- before_del_bond(conf={}, customProperty={})
- after_del_bond(conf={}, customProperty={})
- before_edit_bond(conf={}, customProperty={})
- after_edit_bond(conf={}, customProperty={})
- TBD

General purpose:
- before_persist_network
- after_persist_network


Now we just need to figure out the use cases.

Your input more than welcome...

[1] http://gerrit.ovirt.org/#/c/7224/   - Adding hooks support for NIC hotplug
[2] http://gerrit.ovirt.org/#/c/7547/   - Hook: Cisco VM-FEX support


Regards,
    Igor Lvovsky


From ykaul at redhat.com  Wed Oct 10 14:53:19 2012
From: ykaul at redhat.com (Yaniv Kaul)
Date: Wed, 10 Oct 2012 16:53:19 +0200
Subject: [Engine-devel] Network related hooks in vdsm
In-Reply-To: <205895767.8750976.1349880448089.JavaMail.root@redhat.com>
References: <205895767.8750976.1349880448089.JavaMail.root@redhat.com>
Message-ID: <50758BDF.5020304@redhat.com>

On 10/10/2012 04:47 PM, Igor Lvovsky wrote:
>    Hi everyone,
> As you know vdsm has hooks mechanism and we already support dozen of hooks for different needs.
> Now it's a network's time.
> We would like to get your comments regarding our proposition for network related hooks.
>
> In general we are planning to prepare framework for future support of bunch network related hooks.
> Some of them already proposed by Itzik Brown [1] and Dan Yasny [2].
>
> Below you can find the additional hooks list that we propose:
>
> Note: In the first stage we can implement these hooks without any parameters, just to provide an entry point
>   for simple hooks.
>
> Networks manipulation:
> - before_add_network(conf={}, customProperty={})
> - after_add_network(conf={}, customProperty={})
> - before_del_network(conf={}, customProperty={})
> - after_del_network(conf={}, customProperty={})
> - before_edit_network(conf={}, customProperty={})
> - after_edit_network(conf={}, customProperty={})
> - TBD
>
> Bondings manipulations:

Bond might be interesting because it may require switch configuration - 
but so will VLAN changes, so perhaps triggers in VLAN changes are 
worthwhile as well.
Y.

> - before_add_bond(conf={}, customProperty={})
> - after_add_bond(conf={}, customProperty={})
> - before_del_bond(conf={}, customProperty={})
> - after_del_bond(conf={}, customProperty={})
> - before_edit_bond(conf={}, customProperty={})
> - after_edit_bond(conf={}, customProperty={})
> - TBD
>
> General purpose:
> - before_persist_network
> - after_persist_network
>
>
> Now we just need to figure out the use cases.
>
> Your input more than welcome...
>
> [1] http://gerrit.ovirt.org/#/c/7224/   - Adding hooks support for NIC hotplug
> [2] http://gerrit.ovirt.org/#/c/7547/   - Hook: Cisco VM-FEX support
>
>
> Regards,
>      Igor Lvovsky
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel



From simon at redhat.com  Wed Oct 10 15:03:52 2012
From: simon at redhat.com (Simon Grinberg)
Date: Wed, 10 Oct 2012 11:03:52 -0400 (EDT)
Subject: [Engine-devel] Network related hooks in vdsm
In-Reply-To: <205895767.8750976.1349880448089.JavaMail.root@redhat.com>
Message-ID: <964654942.10053240.1349881432353.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Igor Lvovsky" <ilvovsky at redhat.com>
> To: "vdsm-devel" <vdsm-devel at lists.fedorahosted.org>, "engine-devel" <engine-devel at ovirt.org>
> Cc: "Dan Yasny" <dyasny at redhat.com>
> Sent: Wednesday, October 10, 2012 4:47:28 PM
> Subject: [Engine-devel] Network related hooks in vdsm
> 
> Hi everyone,
> As you know vdsm has hooks mechanism and we already support dozen of
> hooks for different needs.
> Now it's a network's time.
> We would like to get your comments regarding our proposition for
> network related hooks.
> 
> In general we are planning to prepare framework for future support of
> bunch network related hooks.
> Some of them already proposed by Itzik Brown [1] and Dan Yasny [2].
> 
> Below you can find the additional hooks list that we propose:
> 
> Note: In the first stage we can implement these hooks without any
> parameters, just to provide an entry point
>  for simple hooks.
> 
> Networks manipulation:
> - before_add_network(conf={}, customProperty={})
> - after_add_network(conf={}, customProperty={})
> - before_del_network(conf={}, customProperty={})
> - after_del_network(conf={}, customProperty={})
> - before_edit_network(conf={}, customProperty={})
> - after_edit_network(conf={}, customProperty={})
> - TBD

+ VM networking related points in addition to before/after vm start/stop
before_hotplug_nic(conf={}, customProperty={})
*after_hotplug_nic(conf={}, customProperty={})
before_hotunplug_nic(conf={}, customProperty={})
*after_hotunplug_nic(conf={}, customProperty={})

* Not sure about use case for those two 

The above will require VM IDs and networks? Sorry that I did not look into the actual implementation of the above naming is more of a guess work, but I think the meaning is clear. There may be other VM networking related entry points I've missed. 

> 
> Bondings manipulations:
> - before_add_bond(conf={}, customProperty={})
> - after_add_bond(conf={}, customProperty={})
> - before_del_bond(conf={}, customProperty={})
> - after_del_bond(conf={}, customProperty={})
> - before_edit_bond(conf={}, customProperty={})
> - after_edit_bond(conf={}, customProperty={})
> - TBD
> 
> General purpose:
> - before_persist_network
> - after_persist_network
> 
> 
> Now we just need to figure out the use cases.
> 
> Your input more than welcome...
> 
> [1] http://gerrit.ovirt.org/#/c/7224/   - Adding hooks support for
> NIC hotplug
> [2] http://gerrit.ovirt.org/#/c/7547/   - Hook: Cisco VM-FEX support
> 
> 
> Regards,
>     Igor Lvovsky
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From mpastern at redhat.com  Wed Oct 10 15:06:35 2012
From: mpastern at redhat.com (Michael Pasternak)
Date: Wed, 10 Oct 2012 17:06:35 +0200
Subject: [Engine-devel] allowing user taking vm from vmpool in user-api
In-Reply-To: <886375362.6446497.1349284604307.JavaMail.root@redhat.com>
References: <886375362.6446497.1349284604307.JavaMail.root@redhat.com>
Message-ID: <50758EFB.4000007@redhat.com>

On 10/03/2012 07:16 PM, Simon Grinberg wrote:
> 
> 
> ----- Original Message -----
>> From: "Michael Pasternak" <mpastern at redhat.com>
>> To: "engine-devel" <engine-devel at ovirt.org>, "Miki Kenneth" <mkenneth at redhat.com>
>> Cc: "Michal Skrivanek" <mskrivan at redhat.com>
>> Sent: Wednesday, October 3, 2012 6:13:39 PM
>> Subject: [Engine-devel] allowing user taking vm from vmpool in user-api
>>
>>
>> Apparently we have gap in vmpool for user-api, we need make users
>> being
>> able allocating vm/s to themselves,
>>
>> it can be done via new action on vmpool,
>>
>> URI: /api/vmpools/xxx/allocate|rel=allocate
>>
>> thoughts?
> 
> What is the response a VM ref?  

yes.

> 
>>
>>
>> --
>>
>> Michael Pasternak
>> RedHat, ENG-Virtualization R&D
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From ilvovsky at redhat.com  Wed Oct 10 15:27:13 2012
From: ilvovsky at redhat.com (Igor Lvovsky)
Date: Wed, 10 Oct 2012 11:27:13 -0400 (EDT)
Subject: [Engine-devel] Network related hooks in vdsm
In-Reply-To: <964654942.10053240.1349881432353.JavaMail.root@redhat.com>
Message-ID: <2119385647.8770771.1349882833773.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Simon Grinberg" <simon at redhat.com>
> To: "Igor Lvovsky" <ilvovsky at redhat.com>
> Cc: "Dan Yasny" <dyasny at redhat.com>, "vdsm-devel" <vdsm-devel at lists.fedorahosted.org>, "engine-devel"
> <engine-devel at ovirt.org>
> Sent: Wednesday, October 10, 2012 5:03:52 PM
> Subject: Re: [Engine-devel] Network related hooks in vdsm
> 
> 
> 
> ----- Original Message -----
> > From: "Igor Lvovsky" <ilvovsky at redhat.com>
> > To: "vdsm-devel" <vdsm-devel at lists.fedorahosted.org>,
> > "engine-devel" <engine-devel at ovirt.org>
> > Cc: "Dan Yasny" <dyasny at redhat.com>
> > Sent: Wednesday, October 10, 2012 4:47:28 PM
> > Subject: [Engine-devel] Network related hooks in vdsm
> > 
> > Hi everyone,
> > As you know vdsm has hooks mechanism and we already support dozen
> > of
> > hooks for different needs.
> > Now it's a network's time.
> > We would like to get your comments regarding our proposition for
> > network related hooks.
> > 
> > In general we are planning to prepare framework for future support
> > of
> > bunch network related hooks.
> > Some of them already proposed by Itzik Brown [1] and Dan Yasny [2].
> > 
> > Below you can find the additional hooks list that we propose:
> > 
> > Note: In the first stage we can implement these hooks without any
> > parameters, just to provide an entry point
> >  for simple hooks.
> > 
> > Networks manipulation:
> > - before_add_network(conf={}, customProperty={})
> > - after_add_network(conf={}, customProperty={})
> > - before_del_network(conf={}, customProperty={})
> > - after_del_network(conf={}, customProperty={})
> > - before_edit_network(conf={}, customProperty={})
> > - after_edit_network(conf={}, customProperty={})
> > - TBD
> 
> + VM networking related points in addition to before/after vm
> start/stop
> before_hotplug_nic(conf={}, customProperty={})
> *after_hotplug_nic(conf={}, customProperty={})
> before_hotunplug_nic(conf={}, customProperty={})
> *after_hotunplug_nic(conf={}, customProperty={})
> 
> * Not sure about use case for those two
> 

Yep, part of them already proposed by Itzik (look at [1])

> The above will require VM IDs and networks? Sorry that I did not look
> into the actual implementation of the above naming is more of a
> guess work, but I think the meaning is clear. There may be other VM
> networking related entry points I've missed.
> 
> > 
> > Bondings manipulations:
> > - before_add_bond(conf={}, customProperty={})
> > - after_add_bond(conf={}, customProperty={})
> > - before_del_bond(conf={}, customProperty={})
> > - after_del_bond(conf={}, customProperty={})
> > - before_edit_bond(conf={}, customProperty={})
> > - after_edit_bond(conf={}, customProperty={})
> > - TBD
> > 
> > General purpose:
> > - before_persist_network
> > - after_persist_network
> > 
> > 
> > Now we just need to figure out the use cases.
> > 
> > Your input more than welcome...
> > 
> > [1] http://gerrit.ovirt.org/#/c/7224/   - Adding hooks support for
> > NIC hotplug
> > [2] http://gerrit.ovirt.org/#/c/7547/   - Hook: Cisco VM-FEX
> > support
> > 
> > 
> > Regards,
> >     Igor Lvovsky
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> 


From ilvovsky at redhat.com  Wed Oct 10 15:29:47 2012
From: ilvovsky at redhat.com (Igor Lvovsky)
Date: Wed, 10 Oct 2012 11:29:47 -0400 (EDT)
Subject: [Engine-devel] Network related hooks in vdsm
In-Reply-To: <50758BDF.5020304@redhat.com>
Message-ID: <1967012910.8772710.1349882987252.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Yaniv Kaul" <ykaul at redhat.com>
> To: "Igor Lvovsky" <ilvovsky at redhat.com>
> Cc: "vdsm-devel" <vdsm-devel at lists.fedorahosted.org>, "engine-devel" <engine-devel at ovirt.org>, "Dan Yasny"
> <dyasny at redhat.com>
> Sent: Wednesday, October 10, 2012 4:53:19 PM
> Subject: Re: [Engine-devel] Network related hooks in vdsm
> 
> On 10/10/2012 04:47 PM, Igor Lvovsky wrote:
> >    Hi everyone,
> > As you know vdsm has hooks mechanism and we already support dozen
> > of hooks for different needs.
> > Now it's a network's time.
> > We would like to get your comments regarding our proposition for
> > network related hooks.
> >
> > In general we are planning to prepare framework for future support
> > of bunch network related hooks.
> > Some of them already proposed by Itzik Brown [1] and Dan Yasny [2].
> >
> > Below you can find the additional hooks list that we propose:
> >
> > Note: In the first stage we can implement these hooks without any
> > parameters, just to provide an entry point
> >   for simple hooks.
> >
> > Networks manipulation:
> > - before_add_network(conf={}, customProperty={})
> > - after_add_network(conf={}, customProperty={})
> > - before_del_network(conf={}, customProperty={})
> > - after_del_network(conf={}, customProperty={})
> > - before_edit_network(conf={}, customProperty={})
> > - after_edit_network(conf={}, customProperty={})
> > - TBD
> >
> > Bondings manipulations:
> 
> Bond might be interesting because it may require switch configuration
> -
> but so will VLAN changes, so perhaps triggers in VLAN changes are
> worthwhile as well.

You are right, but in our implementation VLAN changes are part of network manipulation.
So, it's already covered by list above

> Y.
> 
> > - before_add_bond(conf={}, customProperty={})
> > - after_add_bond(conf={}, customProperty={})
> > - before_del_bond(conf={}, customProperty={})
> > - after_del_bond(conf={}, customProperty={})
> > - before_edit_bond(conf={}, customProperty={})
> > - after_edit_bond(conf={}, customProperty={})
> > - TBD
> >
> > General purpose:
> > - before_persist_network
> > - after_persist_network
> >
> >
> > Now we just need to figure out the use cases.
> >
> > Your input more than welcome...
> >
> > [1] http://gerrit.ovirt.org/#/c/7224/   - Adding hooks support for
> > NIC hotplug
> > [2] http://gerrit.ovirt.org/#/c/7547/   - Hook: Cisco VM-FEX
> > support
> >
> >
> > Regards,
> >      Igor Lvovsky
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> 


From simon at redhat.com  Wed Oct 10 15:35:03 2012
From: simon at redhat.com (Simon Grinberg)
Date: Wed, 10 Oct 2012 11:35:03 -0400 (EDT)
Subject: [Engine-devel] Network related hooks in vdsm
In-Reply-To: <2119385647.8770771.1349882833773.JavaMail.root@redhat.com>
Message-ID: <780474999.10074074.1349883303799.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Igor Lvovsky" <ilvovsky at redhat.com>
> To: "Simon Grinberg" <simon at redhat.com>
> Cc: "Dan Yasny" <dyasny at redhat.com>, "engine-devel" <engine-devel at ovirt.org>, "vdsm-devel"
> <vdsm-devel at lists.fedorahosted.org>
> Sent: Wednesday, October 10, 2012 5:27:13 PM
> Subject: Re: [Engine-devel] Network related hooks in vdsm
> 
> 
> 
> ----- Original Message -----
> > From: "Simon Grinberg" <simon at redhat.com>
> > To: "Igor Lvovsky" <ilvovsky at redhat.com>
> > Cc: "Dan Yasny" <dyasny at redhat.com>, "vdsm-devel"
> > <vdsm-devel at lists.fedorahosted.org>, "engine-devel"
> > <engine-devel at ovirt.org>
> > Sent: Wednesday, October 10, 2012 5:03:52 PM
> > Subject: Re: [Engine-devel] Network related hooks in vdsm
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Igor Lvovsky" <ilvovsky at redhat.com>
> > > To: "vdsm-devel" <vdsm-devel at lists.fedorahosted.org>,
> > > "engine-devel" <engine-devel at ovirt.org>
> > > Cc: "Dan Yasny" <dyasny at redhat.com>
> > > Sent: Wednesday, October 10, 2012 4:47:28 PM
> > > Subject: [Engine-devel] Network related hooks in vdsm
> > > 
> > > Hi everyone,
> > > As you know vdsm has hooks mechanism and we already support dozen
> > > of
> > > hooks for different needs.
> > > Now it's a network's time.
> > > We would like to get your comments regarding our proposition for
> > > network related hooks.
> > > 
> > > In general we are planning to prepare framework for future
> > > support
> > > of
> > > bunch network related hooks.
> > > Some of them already proposed by Itzik Brown [1] and Dan Yasny
> > > [2].
> > > 
> > > Below you can find the additional hooks list that we propose:
> > > 
> > > Note: In the first stage we can implement these hooks without any
> > > parameters, just to provide an entry point
> > >  for simple hooks.
> > > 
> > > Networks manipulation:
> > > - before_add_network(conf={}, customProperty={})
> > > - after_add_network(conf={}, customProperty={})
> > > - before_del_network(conf={}, customProperty={})
> > > - after_del_network(conf={}, customProperty={})
> > > - before_edit_network(conf={}, customProperty={})
> > > - after_edit_network(conf={}, customProperty={})
> > > - TBD
> > 
> > + VM networking related points in addition to before/after vm
> > start/stop
> > before_hotplug_nic(conf={}, customProperty={})
> > *after_hotplug_nic(conf={}, customProperty={})
> > before_hotunplug_nic(conf={}, customProperty={})
> > *after_hotunplug_nic(conf={}, customProperty={})
> > 
> > * Not sure about use case for those two
> > 
> 
> Yep, part of them already proposed by Itzik (look at [1])

This is what happen when you miss out the end of the email :)

But if I'm reading the comment correctly it indeed doesn't implement two of the 4 above. My '*' was in the wrong location, indeed the two suggested in the patch are the two I can find a use case for, while the other two I'm not sure of but I think should be implemented for completeness.  


> 
> > The above will require VM IDs and networks? Sorry that I did not
> > look
> > into the actual implementation of the above naming is more of a
> > guess work, but I think the meaning is clear. There may be other VM
> > networking related entry points I've missed.
> > 
> > > 
> > > Bondings manipulations:
> > > - before_add_bond(conf={}, customProperty={})
> > > - after_add_bond(conf={}, customProperty={})
> > > - before_del_bond(conf={}, customProperty={})
> > > - after_del_bond(conf={}, customProperty={})
> > > - before_edit_bond(conf={}, customProperty={})
> > > - after_edit_bond(conf={}, customProperty={})
> > > - TBD
> > > 
> > > General purpose:
> > > - before_persist_network
> > > - after_persist_network
> > > 
> > > 
> > > Now we just need to figure out the use cases.
> > > 
> > > Your input more than welcome...
> > > 
> > > [1] http://gerrit.ovirt.org/#/c/7224/   - Adding hooks support
> > > for
> > > NIC hotplug
> > > [2] http://gerrit.ovirt.org/#/c/7547/   - Hook: Cisco VM-FEX
> > > support
> > > 
> > > 
> > > Regards,
> > >     Igor Lvovsky
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > 
> > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From acathrow at redhat.com  Wed Oct 10 19:44:24 2012
From: acathrow at redhat.com (Andrew Cathrow)
Date: Wed, 10 Oct 2012 15:44:24 -0400 (EDT)
Subject: [Engine-devel] Network related hooks in vdsm
In-Reply-To: <50758BDF.5020304@redhat.com>
Message-ID: <33322242.4837.1349898229689.JavaMail.javamailuser@localhost>



----- Original Message -----
> From: "Yaniv Kaul" <ykaul at redhat.com>
> To: "Igor Lvovsky" <ilvovsky at redhat.com>
> Cc: "Dan Yasny" <dyasny at redhat.com>, "engine-devel" <engine-devel at ovirt.org>, "vdsm-devel"
> <vdsm-devel at lists.fedorahosted.org>
> Sent: Wednesday, October 10, 2012 10:53:19 AM
> Subject: Re: [Engine-devel] Network related hooks in vdsm
> 
> On 10/10/2012 04:47 PM, Igor Lvovsky wrote:
> >    Hi everyone,
> > As you know vdsm has hooks mechanism and we already support dozen
> > of hooks for different needs.
> > Now it's a network's time.
> > We would like to get your comments regarding our proposition for
> > network related hooks.
> >
> > In general we are planning to prepare framework for future support
> > of bunch network related hooks.
> > Some of them already proposed by Itzik Brown [1] and Dan Yasny [2].
> >
> > Below you can find the additional hooks list that we propose:
> >
> > Note: In the first stage we can implement these hooks without any
> > parameters, just to provide an entry point
> >   for simple hooks.
> >
> > Networks manipulation:
> > - before_add_network(conf={}, customProperty={})
> > - after_add_network(conf={}, customProperty={})
> > - before_del_network(conf={}, customProperty={})
> > - after_del_network(conf={}, customProperty={})
> > - before_edit_network(conf={}, customProperty={})
> > - after_edit_network(conf={}, customProperty={})
> > - TBD
> >
> > Bondings manipulations:
> 
> Bond might be interesting because it may require switch configuration
> -
> but so will VLAN changes, so perhaps triggers in VLAN changes are
> worthwhile as well.
> Y.
> 
> > - before_add_bond(conf={}, customProperty={})
> > - after_add_bond(conf={}, customProperty={})
> > - before_del_bond(conf={}, customProperty={})
> > - after_del_bond(conf={}, customProperty={})
> > - before_edit_bond(conf={}, customProperty={})
> > - after_edit_bond(conf={}, customProperty={})
> > - TBD
> >
> > General purpose:
> > - before_persist_network
> > - after_persist_network

What about some way of doing a push that's not tied to an event - if we want to "push" something



> >
> >
> > Now we just need to figure out the use cases.
> >
> > Your input more than welcome...
> >
> > [1] http://gerrit.ovirt.org/#/c/7224/   - Adding hooks support for
> > NIC hotplug
> > [2] http://gerrit.ovirt.org/#/c/7547/   - Hook: Cisco VM-FEX
> > support
> >
> >
> > Regards,
> >      Igor Lvovsky
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From danken at redhat.com  Thu Oct 11 08:08:04 2012
From: danken at redhat.com (Dan Kenigsberg)
Date: Thu, 11 Oct 2012 10:08:04 +0200
Subject: [Engine-devel] Network related hooks in vdsm
In-Reply-To: <33322242.4837.1349898229689.JavaMail.javamailuser@localhost>
References: <50758BDF.5020304@redhat.com>
	<33322242.4837.1349898229689.JavaMail.javamailuser@localhost>
Message-ID: <20121011080804.GC22797@redhat.com>

On Wed, Oct 10, 2012 at 03:44:24PM -0400, Andrew Cathrow wrote:
> 
> 
> ----- Original Message -----
> > From: "Yaniv Kaul" <ykaul at redhat.com>
> > To: "Igor Lvovsky" <ilvovsky at redhat.com>
> > Cc: "Dan Yasny" <dyasny at redhat.com>, "engine-devel" <engine-devel at ovirt.org>, "vdsm-devel"
> > <vdsm-devel at lists.fedorahosted.org>
> > Sent: Wednesday, October 10, 2012 10:53:19 AM
> > Subject: Re: [Engine-devel] Network related hooks in vdsm
> > 
> > On 10/10/2012 04:47 PM, Igor Lvovsky wrote:
> > >    Hi everyone,
> > > As you know vdsm has hooks mechanism and we already support dozen
> > > of hooks for different needs.
> > > Now it's a network's time.
> > > We would like to get your comments regarding our proposition for
> > > network related hooks.
> > >
> > > In general we are planning to prepare framework for future support
> > > of bunch network related hooks.
> > > Some of them already proposed by Itzik Brown [1] and Dan Yasny [2].
> > >
> > > Below you can find the additional hooks list that we propose:
> > >
> > > Note: In the first stage we can implement these hooks without any
> > > parameters, just to provide an entry point
> > >   for simple hooks.
> > >
> > > Networks manipulation:
> > > - before_add_network(conf={}, customProperty={})
> > > - after_add_network(conf={}, customProperty={})
> > > - before_del_network(conf={}, customProperty={})
> > > - after_del_network(conf={}, customProperty={})
> > > - before_edit_network(conf={}, customProperty={})
> > > - after_edit_network(conf={}, customProperty={})
> > > - TBD
> > >
> > > Bondings manipulations:
> > 
> > Bond might be interesting because it may require switch configuration
> > -
> > but so will VLAN changes, so perhaps triggers in VLAN changes are
> > worthwhile as well.
> > Y.
> > 
> > > - before_add_bond(conf={}, customProperty={})
> > > - after_add_bond(conf={}, customProperty={})
> > > - before_del_bond(conf={}, customProperty={})
> > > - after_del_bond(conf={}, customProperty={})
> > > - before_edit_bond(conf={}, customProperty={})
> > > - after_edit_bond(conf={}, customProperty={})
> > > - TBD
> > >
> > > General purpose:
> > > - before_persist_network
> > > - after_persist_network
> 
> What about some way of doing a push that's not tied to an event - if we want to "push" something

Would you elaborate on that? I don't understand the English.

Are you looking for a hook that is not tied to a specific network,
rather a before_setupnetworks/after_setupnetworks ?

Dan.


From eedri at redhat.com  Thu Oct 11 09:00:29 2012
From: eedri at redhat.com (Eyal Edri)
Date: Thu, 11 Oct 2012 05:00:29 -0400 (EDT)
Subject: [Engine-devel] jenkins ovirt-engine_create_rpms project
In-Reply-To: <eaf59ce692a35ad0e06edc23f85e1c83d4626f19@mail.qip.ru>
Message-ID: <1260984064.10518260.1349946029285.JavaMail.root@redhat.com>

thanks for pointing that out!

for some reason the job was missing the poll scm value, and didn't have a trigger.

it will run run on every commit to ovirt-engine.

Eyal.

----- Original Message -----
> From: ovirt at qip.ru
> To: engine-devel at ovirt.org
> Sent: Tuesday, October 9, 2012 10:18:54 AM
> Subject: [Engine-devel] jenkins ovirt-engine_create_rpms project
> 
> Hi,
> 
> last start of ovirt-engine_create_rpms job was more than one month
> ago, may be it is possible to start ovirt-engine_create_rpms once a
> day before publish_ovirt_rpms_nightly ?
> 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From ovedo at redhat.com  Thu Oct 11 10:20:56 2012
From: ovedo at redhat.com (Oved Ourfalli)
Date: Thu, 11 Oct 2012 06:20:56 -0400 (EDT)
Subject: [Engine-devel] [Users] oVirt MCollective Agent
In-Reply-To: <CAPXYmTrtsjL8304x7Gg11Z=109vE2knuX75V06_-X1gDe6oH3A@mail.gmail.com>
Message-ID: <1954477467.15073892.1349950856535.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Marco Mornati" <mornatim at gmail.com>
> To: users at ovirt.org
> Sent: Thursday, October 11, 2012 12:06:23 PM
> Subject: [Users] oVirt MCollective Agent
> 
> 
> Hello guys,
> 
> 
> I'm working on a cloud provisioning automatic tool and control (
> http://www.kermit.fr ) and I'm actually creating the module to
> control the virtual farm based on oVirt (and RHEV 3.1 when will be
> out ;)).
> 
> 
> That means I created a module to control oVirt using MCollective (
> http://docs.puppetlabs.com/mcollective/ ).
> 
> 
> You can find some information about the agent and the usage on my
> blog, here:
> http://blog.mornati.net/2012/10/09/mcollective-ovirt-agent/
> And source of the Mcollective oVirt agent here:
> https://github.com/thinkfr/mcoplugins (ovirt.rb and ovirt.ddl).
> 
> 
> Even if you are not interested in the agent, I think the ruby file
> could be useful if you want to use the rbovirt API. I couldn't find
> any doc about that API on the net, so I created the agent looking to
> ruby api sources (I think any good project should have a little bit
> of documentation!!!).
> 

Nice work!
As for rbovirt, I saw that indeed there isn't a lot of documentation on it.
You can have a look at deltacloud, which uses it as well, to see some usage samples (although some are similar to what you already did).
I hope rbovirt will expand more, to include some new features that were added in 3.1.

You can see the driver they wrote in:
https://github.com/apache/deltacloud/blob/master/server/lib/deltacloud/drivers/rhevm/rhevm_driver.rb

I'm currently working on testing EC2/CIMI API calls using deltacloud, and pushing some fixes both in deltacloud in rbovirt, but there is indeed a lot of work that needs to be done there.

Feel free to contact this mailing list, or the engine-devel mailing list if you have issues, and we'll help.

Good luck!
Oved

> 
> Anyway, let me know if you are interested and if you have any
> suggestion and idea about it.
> 
> 
> Marco
> 
> 
> _______________________________________________
> Users mailing list
> Users at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
> 


From rgolan at redhat.com  Thu Oct 11 10:22:51 2012
From: rgolan at redhat.com (Roy Golan)
Date: Thu, 11 Oct 2012 12:22:51 +0200
Subject: [Engine-devel] libosinfo integration
In-Reply-To: <1716804551.237454.1348516868577.JavaMail.root@redhat.com>
References: <1716804551.237454.1348516868577.JavaMail.root@redhat.com>
Message-ID: <50769DFB.5070703@redhat.com>

After considering the pros and cons and making poc's I've decided to 
take the direct XML and java pure implementation.
http://gerrit.ovirt.org/#/c/8472/
http://gerrit.ovirt.org/#/c/8473/

the main motivation was is that the XML loading was fast and standard. 
it is very easy to expose a subset of the API while leaving behind the 
extra library magic which we don't currently need.
Maybe at some point the inheritance feature will come in handy and the 
jgir implementation will be done so we could switch to it (I'm really 
not sure whats it there which is not complete)


On 09/24/2012 10:01 PM, Alon Bar-Lev wrote:
>
> ----- Original Message -----
>> From: "Juan Hernandez" <jhernand at redhat.com>
>> To: "Alon Bar-Lev" <alonbl at redhat.com>
>> Cc: "arch" <arch at ovirt.org>, engine-devel at ovirt.org, "Daniel P. Berrange" <berrange at redhat.com>
>> Sent: Monday, September 24, 2012 9:33:38 PM
>> Subject: Re: [Engine-devel] libosinfo integration
>>
>> On 09/24/2012 08:59 PM, Alon Bar-Lev wrote:
>>>
>>> ----- Original Message -----
>>>> From: "Juan Hernandez" <jhernand at redhat.com>
>>>> To: "Daniel P. Berrange" <berrange at redhat.com>
>>>> Cc: "arch" <arch at ovirt.org>, engine-devel at ovirt.org
>>>> Sent: Monday, September 24, 2012 6:30:43 PM
>>>> Subject: Re: [Engine-devel] libosinfo integration
>>>>
>>>> On 09/24/2012 05:24 PM, Daniel P. Berrange wrote:
>>>>> On Mon, Sep 24, 2012 at 04:51:37PM +0200, Roy Golan wrote:
>>>>>> Here's a draft wiki of the libosinfo integration with the engine
>>>>>> http://wiki.ovirt.org/wiki/Libosinfo
>>>>>>
>>>>>> please share your comments on this thread and I'll update the
>>>>>> wiki
>>>>>> accordingly.
>>>>> As a libosinfo maintainer I strongly discourage you from writing
>>>>> a
>>>>> custom
>>>>> API directly against the XML. While the format is stable from the
>>>>> POV
>>>>> that vendors/users can create new XML docs for new/customized OS
>>>>> variants
>>>>> they have, we do not consider it something for applications to be
>>>>> using
>>>>> directly. The libosinfo library API includes alot of logic beyond
>>>>> simply
>>>>> being an convenient way to process the XML. In particular dealing
>>>>> with
>>>>> the inheritance of data across OS, searching for data across a
>>>>> variety
>>>>> of data sources, relying on GIO for URI resolving, live update of
>>>>> the
>>>>> database, and more.
>>>>>
>>>>> We're also not really interested in maintaining manually written
>>>>> bindings
>>>>> for any languages. Rather than putting effort into such bindings
>>>>> for Java,
>>>>> time is better spent on finishing the GOBject introspection
>>>>> mapping
>>>>> layer
>>>>> for Java. There was a proof of concept, which was never finished
>>>>> /
>>>>> updated
>>>>> to the final introspection spec, which can be used as a basis for
>>>>> ongoing
>>>>> development.
>>>>>
>>>>>   https://live.gnome.org/JGIR
>>>>>
>>>>> This work will be applicable way beyond just libosinfo, to a wide
>>>>> variety of useful APIs. Of possible interest to VDSM in the
>>>>> future
>>>>> will
>>>>> be things like the new libvirt-designer & libvirt-builder APIs
>>>>> which
>>>>> are going to provide a bridge between libvirt + libosinfo to
>>>>> simply
>>>>> life for application developers constructing XML for provisioning
>>>>> guests.
>>>> I think that the use of JGIR has already been discussed as a way
>>>> to
>>>> interface the engine with libvdsm.so:
>>>>
>>>> http://lists.ovirt.org/pipermail/arch/2012-August/000760.html
>>>>
>>>> If I remember correctly the outcome of that discussion was that it
>>>> shouldn't be used because it is considered dangerous to use native
>>>> libraries from Java and because JGIR itself is very outdated. I
>>>> don't
>>>> 100% agree with the first part, but the second part is completely
>>>> true.
>>>>
>>>> Anyhow, as it seems to be the right way to interface with
>>>> libosinfo
>>>> and
>>>> future libvirt capabilities, we may want to rethink and put some
>>>> effort
>>>> to bring it up to date.
>>> I don't think Java should go native to obtain data, using JNI or
>>> whatever native interface that is offered. It can totally break
>>> the JVM and cause leaks and stability issues JRE would like to
>>> avoid.
>> This is were I disagree, only a bit. It is true that using JNI
>> *without
>> care* can totally break the JVM, generate leaks, and bring down all
>> the
>> application. But if the JNI layer is developed carefully this should
>> not
>> be more risky than any of the other multiple native libraries that
>> you
>> use every day from Java without noticing.
>> In addition JGIR is based on JNA (which is well maintained and
>> stable)
>> and doesn't include any "dangerous" native C code.
>>
> Well, you can call me old fashioned...
>
> But I don't think that any none critical task should be run out of process of the production component.
>
> It is not GObject layer I am afraid of, it is what it eventually runs.
>
> I believe that the data provided by libosinfo is not vital for our runtime, no problem in fetching it before start.
>
> And again, I don't think data provider should be language binding... this concept alone is making me scared, as instead of using well defined data container people will start to use mesh of components... I don't see how you can stabilize an application this way.
>
> For the native library that you use "every day", I don't know what you referring to, I've done lsof of engine and saw no exception... which other native library we use these days?
>   
>>> Having language binding for data access logic seems a bit strange
>>> for me, as it should be easy to stabilize a schema either using
>>> XML or a set of CSVs, for all to read and use.
>>>
>>> I do understand why JNI is to be used when OS specific features are
>>> to be used, for example unix domain sockets, shared memory,
>>> security, but not for data access.
>>>
>>> The alternatives would be:
>>>
>>> 1. Run a python program at ovirt-engine start-up, use the python
>>> API to fetch the data we need, and generate our own tiny XML of
>>> the subset or even load it to the database. We can use the output
>>> safely in Java. Disadvantage is that we need to stop/start service
>>> or have a "refresh" verb for reload after libosinfo update.
>>>
>>> 2. When data is requested, execute a python process with cmdline
>>> arguments and get result from stdout of the process. The
>>> disadvantage is the overhead of clone().
>>>
>>> 3. Read the XML directly on runtime, disadvantage is if XML is
>>> changed.
>>>
>>> 4. Use the libosinfo python API during build and distribute an
>>> update to the information in versions of ovirt, disadvantage is
>>> slow refresh of data, not sure how often this data is updated.
>>>
>>> 5. Provide a web service that has specific XML-RPC / RESTful API,
>>> that can provide data out of the libosinfo, and publish it at
>>> internet. Configure ovirt to use it, disadvantage is the need for
>>> internet connection.
>>>
>>> 6. Configure cgi-bin locally at apache where ovirt is running,
>>> which provide XML-RPC / RESTful API, and access it locally.
>>>
>>> In any case I would avoid exiting the JVM to interact with data
>>> provider.
>>>
>>> Regards,
>>> Alon.
>>>
>>
>> --
>> Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
>> 3?D, 28016 Madrid, Spain
>> Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B82657941 - Red Hat
>> S.L.
>>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel



From alonbl at redhat.com  Thu Oct 11 10:25:44 2012
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Thu, 11 Oct 2012 06:25:44 -0400 (EDT)
Subject: [Engine-devel] libosinfo integration
In-Reply-To: <50769DFB.5070703@redhat.com>
Message-ID: <1442944759.2988100.1349951144432.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Roy Golan" <rgolan at redhat.com>
> To: engine-devel at ovirt.org
> Sent: Thursday, October 11, 2012 12:22:51 PM
> Subject: Re: [Engine-devel] libosinfo integration
> 
> After considering the pros and cons and making poc's I've decided to
> take the direct XML and java pure implementation.
> http://gerrit.ovirt.org/#/c/8472/
> http://gerrit.ovirt.org/#/c/8473/
> 
> the main motivation was is that the XML loading was fast and
> standard.
> it is very easy to expose a subset of the API while leaving behind
> the
> extra library magic which we don't currently need.
> Maybe at some point the inheritance feature will come in handy and
> the
> jgir implementation will be done so we could switch to it (I'm really
> not sure whats it there which is not complete)

Great!
This is the simplest solution indeed.
Me happy :)))

> 
> 
> On 09/24/2012 10:01 PM, Alon Bar-Lev wrote:
> >
> > ----- Original Message -----
> >> From: "Juan Hernandez" <jhernand at redhat.com>
> >> To: "Alon Bar-Lev" <alonbl at redhat.com>
> >> Cc: "arch" <arch at ovirt.org>, engine-devel at ovirt.org, "Daniel P.
> >> Berrange" <berrange at redhat.com>
> >> Sent: Monday, September 24, 2012 9:33:38 PM
> >> Subject: Re: [Engine-devel] libosinfo integration
> >>
> >> On 09/24/2012 08:59 PM, Alon Bar-Lev wrote:
> >>>
> >>> ----- Original Message -----
> >>>> From: "Juan Hernandez" <jhernand at redhat.com>
> >>>> To: "Daniel P. Berrange" <berrange at redhat.com>
> >>>> Cc: "arch" <arch at ovirt.org>, engine-devel at ovirt.org
> >>>> Sent: Monday, September 24, 2012 6:30:43 PM
> >>>> Subject: Re: [Engine-devel] libosinfo integration
> >>>>
> >>>> On 09/24/2012 05:24 PM, Daniel P. Berrange wrote:
> >>>>> On Mon, Sep 24, 2012 at 04:51:37PM +0200, Roy Golan wrote:
> >>>>>> Here's a draft wiki of the libosinfo integration with the
> >>>>>> engine
> >>>>>> http://wiki.ovirt.org/wiki/Libosinfo
> >>>>>>
> >>>>>> please share your comments on this thread and I'll update the
> >>>>>> wiki
> >>>>>> accordingly.
> >>>>> As a libosinfo maintainer I strongly discourage you from
> >>>>> writing
> >>>>> a
> >>>>> custom
> >>>>> API directly against the XML. While the format is stable from
> >>>>> the
> >>>>> POV
> >>>>> that vendors/users can create new XML docs for new/customized
> >>>>> OS
> >>>>> variants
> >>>>> they have, we do not consider it something for applications to
> >>>>> be
> >>>>> using
> >>>>> directly. The libosinfo library API includes alot of logic
> >>>>> beyond
> >>>>> simply
> >>>>> being an convenient way to process the XML. In particular
> >>>>> dealing
> >>>>> with
> >>>>> the inheritance of data across OS, searching for data across a
> >>>>> variety
> >>>>> of data sources, relying on GIO for URI resolving, live update
> >>>>> of
> >>>>> the
> >>>>> database, and more.
> >>>>>
> >>>>> We're also not really interested in maintaining manually
> >>>>> written
> >>>>> bindings
> >>>>> for any languages. Rather than putting effort into such
> >>>>> bindings
> >>>>> for Java,
> >>>>> time is better spent on finishing the GOBject introspection
> >>>>> mapping
> >>>>> layer
> >>>>> for Java. There was a proof of concept, which was never
> >>>>> finished
> >>>>> /
> >>>>> updated
> >>>>> to the final introspection spec, which can be used as a basis
> >>>>> for
> >>>>> ongoing
> >>>>> development.
> >>>>>
> >>>>>   https://live.gnome.org/JGIR
> >>>>>
> >>>>> This work will be applicable way beyond just libosinfo, to a
> >>>>> wide
> >>>>> variety of useful APIs. Of possible interest to VDSM in the
> >>>>> future
> >>>>> will
> >>>>> be things like the new libvirt-designer & libvirt-builder APIs
> >>>>> which
> >>>>> are going to provide a bridge between libvirt + libosinfo to
> >>>>> simply
> >>>>> life for application developers constructing XML for
> >>>>> provisioning
> >>>>> guests.
> >>>> I think that the use of JGIR has already been discussed as a way
> >>>> to
> >>>> interface the engine with libvdsm.so:
> >>>>
> >>>> http://lists.ovirt.org/pipermail/arch/2012-August/000760.html
> >>>>
> >>>> If I remember correctly the outcome of that discussion was that
> >>>> it
> >>>> shouldn't be used because it is considered dangerous to use
> >>>> native
> >>>> libraries from Java and because JGIR itself is very outdated. I
> >>>> don't
> >>>> 100% agree with the first part, but the second part is
> >>>> completely
> >>>> true.
> >>>>
> >>>> Anyhow, as it seems to be the right way to interface with
> >>>> libosinfo
> >>>> and
> >>>> future libvirt capabilities, we may want to rethink and put some
> >>>> effort
> >>>> to bring it up to date.
> >>> I don't think Java should go native to obtain data, using JNI or
> >>> whatever native interface that is offered. It can totally break
> >>> the JVM and cause leaks and stability issues JRE would like to
> >>> avoid.
> >> This is were I disagree, only a bit. It is true that using JNI
> >> *without
> >> care* can totally break the JVM, generate leaks, and bring down
> >> all
> >> the
> >> application. But if the JNI layer is developed carefully this
> >> should
> >> not
> >> be more risky than any of the other multiple native libraries that
> >> you
> >> use every day from Java without noticing.
> >> In addition JGIR is based on JNA (which is well maintained and
> >> stable)
> >> and doesn't include any "dangerous" native C code.
> >>
> > Well, you can call me old fashioned...
> >
> > But I don't think that any none critical task should be run out of
> > process of the production component.
> >
> > It is not GObject layer I am afraid of, it is what it eventually
> > runs.
> >
> > I believe that the data provided by libosinfo is not vital for our
> > runtime, no problem in fetching it before start.
> >
> > And again, I don't think data provider should be language
> > binding... this concept alone is making me scared, as instead of
> > using well defined data container people will start to use mesh of
> > components... I don't see how you can stabilize an application
> > this way.
> >
> > For the native library that you use "every day", I don't know what
> > you referring to, I've done lsof of engine and saw no exception...
> > which other native library we use these days?
> >   
> >>> Having language binding for data access logic seems a bit strange
> >>> for me, as it should be easy to stabilize a schema either using
> >>> XML or a set of CSVs, for all to read and use.
> >>>
> >>> I do understand why JNI is to be used when OS specific features
> >>> are
> >>> to be used, for example unix domain sockets, shared memory,
> >>> security, but not for data access.
> >>>
> >>> The alternatives would be:
> >>>
> >>> 1. Run a python program at ovirt-engine start-up, use the python
> >>> API to fetch the data we need, and generate our own tiny XML of
> >>> the subset or even load it to the database. We can use the output
> >>> safely in Java. Disadvantage is that we need to stop/start
> >>> service
> >>> or have a "refresh" verb for reload after libosinfo update.
> >>>
> >>> 2. When data is requested, execute a python process with cmdline
> >>> arguments and get result from stdout of the process. The
> >>> disadvantage is the overhead of clone().
> >>>
> >>> 3. Read the XML directly on runtime, disadvantage is if XML is
> >>> changed.
> >>>
> >>> 4. Use the libosinfo python API during build and distribute an
> >>> update to the information in versions of ovirt, disadvantage is
> >>> slow refresh of data, not sure how often this data is updated.
> >>>
> >>> 5. Provide a web service that has specific XML-RPC / RESTful API,
> >>> that can provide data out of the libosinfo, and publish it at
> >>> internet. Configure ovirt to use it, disadvantage is the need for
> >>> internet connection.
> >>>
> >>> 6. Configure cgi-bin locally at apache where ovirt is running,
> >>> which provide XML-RPC / RESTful API, and access it locally.
> >>>
> >>> In any case I would avoid exiting the JVM to interact with data
> >>> provider.
> >>>
> >>> Regards,
> >>> Alon.
> >>>
> >>
> >> --
> >> Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3,
> >> planta
> >> 3?D, 28016 Madrid, Spain
> >> Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B82657941 - Red
> >> Hat
> >> S.L.
> >>
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From ewoud+ovirt at kohlvanwijngaarden.nl  Thu Oct 11 10:38:12 2012
From: ewoud+ovirt at kohlvanwijngaarden.nl (Ewoud Kohl van Wijngaarden)
Date: Thu, 11 Oct 2012 12:38:12 +0200
Subject: [Engine-devel] libosinfo integration
In-Reply-To: <50769DFB.5070703@redhat.com>
References: <1716804551.237454.1348516868577.JavaMail.root@redhat.com>
	<50769DFB.5070703@redhat.com>
Message-ID: <20121011103812.GG2094@bogey.xentower.nl>

On Thu, Oct 11, 2012 at 12:22:51PM +0200, Roy Golan wrote:
> After considering the pros and cons and making poc's I've decided to
> take the direct XML and java pure implementation.
> http://gerrit.ovirt.org/#/c/8472/
> http://gerrit.ovirt.org/#/c/8473/

Any particular reason I have no permission to view these?


From alonbl at redhat.com  Thu Oct 11 10:39:48 2012
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Thu, 11 Oct 2012 06:39:48 -0400 (EDT)
Subject: [Engine-devel] libosinfo integration
In-Reply-To: <20121011103812.GG2094@bogey.xentower.nl>
Message-ID: <253089463.2989514.1349951988527.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Ewoud Kohl van Wijngaarden" <ewoud+ovirt at kohlvanwijngaarden.nl>
> To: engine-devel at ovirt.org
> Sent: Thursday, October 11, 2012 12:38:12 PM
> Subject: Re: [Engine-devel] libosinfo integration
> 
> On Thu, Oct 11, 2012 at 12:22:51PM +0200, Roy Golan wrote:
> > After considering the pros and cons and making poc's I've decided
> > to
> > take the direct XML and java pure implementation.
> > http://gerrit.ovirt.org/#/c/8472/
> > http://gerrit.ovirt.org/#/c/8473/
> 
> Any particular reason I have no permission to view these?

I cannot either... it must be a draft.
We should solve the drafts permission issues and make them public.

Alon.


From rgolan at redhat.com  Thu Oct 11 10:45:58 2012
From: rgolan at redhat.com (Roy Golan)
Date: Thu, 11 Oct 2012 12:45:58 +0200
Subject: [Engine-devel] libosinfo integration
In-Reply-To: <253089463.2989514.1349951988527.JavaMail.root@redhat.com>
References: <253089463.2989514.1349951988527.JavaMail.root@redhat.com>
Message-ID: <5076A366.3010309@redhat.com>

On 10/11/2012 12:39 PM, Alon Bar-Lev wrote:
>
> ----- Original Message -----
>> From: "Ewoud Kohl van Wijngaarden" <ewoud+ovirt at kohlvanwijngaarden.nl>
>> To: engine-devel at ovirt.org
>> Sent: Thursday, October 11, 2012 12:38:12 PM
>> Subject: Re: [Engine-devel] libosinfo integration
>>
>> On Thu, Oct 11, 2012 at 12:22:51PM +0200, Roy Golan wrote:
>>> After considering the pros and cons and making poc's I've decided
>>> to
>>> take the direct XML and java pure implementation.
>>> http://gerrit.ovirt.org/#/c/8472/
>>> http://gerrit.ovirt.org/#/c/8473/
>> Any particular reason I have no permission to view these?
> I cannot either... it must be a draft.
> We should solve the drafts permission issues and make them public.
Eedri do you know how to solve this?
I'll just add you manually meanwhile.
> Alon.
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel



From eedri at redhat.com  Thu Oct 11 12:01:30 2012
From: eedri at redhat.com (Eyal Edri)
Date: Thu, 11 Oct 2012 08:01:30 -0400 (EDT)
Subject: [Engine-devel] libosinfo integration
In-Reply-To: <5076A366.3010309@redhat.com>
Message-ID: <1142268273.10811084.1349956890615.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Roy Golan" <rgolan at redhat.com>
> To: engine-devel at ovirt.org
> Sent: Thursday, October 11, 2012 12:45:58 PM
> Subject: Re: [Engine-devel] libosinfo integration
> 
> On 10/11/2012 12:39 PM, Alon Bar-Lev wrote:
> >
> > ----- Original Message -----
> >> From: "Ewoud Kohl van Wijngaarden"
> >> <ewoud+ovirt at kohlvanwijngaarden.nl>
> >> To: engine-devel at ovirt.org
> >> Sent: Thursday, October 11, 2012 12:38:12 PM
> >> Subject: Re: [Engine-devel] libosinfo integration
> >>
> >> On Thu, Oct 11, 2012 at 12:22:51PM +0200, Roy Golan wrote:
> >>> After considering the pros and cons and making poc's I've decided
> >>> to
> >>> take the direct XML and java pure implementation.
> >>> http://gerrit.ovirt.org/#/c/8472/
> >>> http://gerrit.ovirt.org/#/c/8473/
> >> Any particular reason I have no permission to view these?
> > I cannot either... it must be a draft.
> > We should solve the drafts permission issues and make them public.
> Eedri do you know how to solve this?

don't have permissions to gerrit.ovirt.org.
you should ask on infra at ovirt.org

> I'll just add you manually meanwhile.
> > Alon.
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From alonbl at redhat.com  Thu Oct 11 12:03:58 2012
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Thu, 11 Oct 2012 08:03:58 -0400 (EDT)
Subject: [Engine-devel] libosinfo integration
In-Reply-To: <1142268273.10811084.1349956890615.JavaMail.root@redhat.com>
Message-ID: <887352457.2997562.1349957038853.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Eyal Edri" <eedri at redhat.com>
> To: "Roy Golan" <rgolan at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Thursday, October 11, 2012 2:01:30 PM
> Subject: Re: [Engine-devel] libosinfo integration
> 
> 
> 
> ----- Original Message -----
> > From: "Roy Golan" <rgolan at redhat.com>
> > To: engine-devel at ovirt.org
> > Sent: Thursday, October 11, 2012 12:45:58 PM
> > Subject: Re: [Engine-devel] libosinfo integration
> > 
> > On 10/11/2012 12:39 PM, Alon Bar-Lev wrote:
> > >
> > > ----- Original Message -----
> > >> From: "Ewoud Kohl van Wijngaarden"
> > >> <ewoud+ovirt at kohlvanwijngaarden.nl>
> > >> To: engine-devel at ovirt.org
> > >> Sent: Thursday, October 11, 2012 12:38:12 PM
> > >> Subject: Re: [Engine-devel] libosinfo integration
> > >>
> > >> On Thu, Oct 11, 2012 at 12:22:51PM +0200, Roy Golan wrote:
> > >>> After considering the pros and cons and making poc's I've
> > >>> decided
> > >>> to
> > >>> take the direct XML and java pure implementation.
> > >>> http://gerrit.ovirt.org/#/c/8472/
> > >>> http://gerrit.ovirt.org/#/c/8473/
> > >> Any particular reason I have no permission to view these?
> > > I cannot either... it must be a draft.
> > > We should solve the drafts permission issues and make them
> > > public.
> > Eedri do you know how to solve this?
> 
> don't have permissions to gerrit.ovirt.org.
> you should ask on infra at ovirt.org

Eyal, we talked about this.
We should make the access to drafts as public not only to people that are CCed.

> 
> > I'll just add you manually meanwhile.
> > > Alon.
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From mpastern at redhat.com  Thu Oct 11 12:52:26 2012
From: mpastern at redhat.com (Michael Pasternak)
Date: Thu, 11 Oct 2012 14:52:26 +0200
Subject: [Engine-devel] VdcActionType.MoveOrCopyDisk
In-Reply-To: <5076AD34.3090607@redhat.com>
References: <1160667478.9511346.1349954680302.JavaMail.root@redhat.com>
	<5076AD34.3090607@redhat.com>
Message-ID: <5076C10A.3070701@redhat.com>

On 10/11/2012 01:27 PM, Michael Pasternak wrote:
> On 10/11/2012 01:24 PM, Daniel Erez wrote:
>> From the log it seems that only one call to CopyImageVDSCommand disk has been invoked.
>> Where do see it copying all template's disks?
> 
> later when i fetch template's disks they all has new SD in storagedomains LIST 
> (DiskImage.getstorage_ids()).
> 
>>
>> ----- Original Message -----
>>> From: "Michael Pasternak" <mpastern at redhat.com>
>>> To: "Ayal Baron" <abaron at redhat.com>, "Omer Frenkel" <ofrenkel at redhat.com>
>>> Cc: "Daniel Erez" <derez at redhat.com>, "Einav Cohen" <ecohen at redhat.com>
>>> Sent: Thursday, October 11, 2012 1:05:00 PM
>>> Subject: VdcActionType.MoveOrCopyDisk
>>>
>>> AFAIU (from derez) VdcActionType.MoveOrCopyDisk used to copy single
>>> disk to another storagedomain, but i see that it's actually copying all
>>> template's disks to this SD, not sure this expected behaviour ...
>>>
>>>
>>>
>>> 2012-10-11 12:47:32,144 INFO
>>>  [org.ovirt.engine.core.bll.MoveOrCopyDiskCommand]
>>> (http--0.0.0.0-8080-1) [4473e7ae] Lock Acquired to object EngineLock
>>> [exclusiveLocks= key:
>>> 01f14d07-b519-4d2f-b573-b0f8a200cb3f value: DISK
>>> , sharedLocks= key: 05ad22e4-a1c4-4caf-97ab-48127233ca24 value:
>>> TEMPLATE
>>> ]
>>> 2012-10-11 12:47:32,277 INFO
>>>  [org.ovirt.engine.core.bll.MoveOrCopyDiskCommand]
>>> (http--0.0.0.0-8080-1) [4473e7ae] Running command:
>>> MoveOrCopyDiskCommand internal: false.
>>> Entities affected :  ID: 01f14d07-b519-4d2f-b573-b0f8a200cb3f Type:
>>> Disk
>>> 2012-10-11 12:47:32,399 INFO
>>>  [org.ovirt.engine.core.bll.MoveOrCopyImageGroupCommand]
>>> (http--0.0.0.0-8080-1) [4473e7ae] Running command:
>>> MoveOrCopyImageGroupCommand
>>> internal: true. Entities affected :  ID:
>>> 47dd3e38-c252-4586-b180-afc8e8011df1 Type: Storage
>>> 2012-10-11 12:47:32,416 INFO
>>>  [org.ovirt.engine.core.vdsbroker.irsbroker.CopyImageVDSCommand]
>>> (http--0.0.0.0-8080-1) [4473e7ae] START, CopyImageVDSCommand(
>>> storagePoolId =
>>> bfe850fc-14d0-4a06-a765-520a2b9e59e4, ignoreFailoverLimit = false,
>>> compatabilityVersion = 3.0, storageDomainId =
>>> 48e1c5d2-9e46-4824-b45c-fd8d8fe6a85a, imageGroupId =
>>> 01f14d07-b519-4d2f-b573-b0f8a200cb3f, imageId =
>>> f964947b-c88a-4c7e-aae1-7d8276e6eb23, dstImageGroupId =
>>> 01f14d07-b519-4d2f-b573-b0f8a200cb3f, vmId =
>>> 00000000-0000-0000-0000-000000000000, dstImageId =
>>> f964947b-c88a-4c7e-aae1-7d8276e6eb23, imageDescription = ,
>>> dstStorageDomainId = 47dd3e38-c252-4586-b180-afc8e8011df1,
>>> copyVolumeType = SharedVol, volumeFormat = RAW, preallocate = Sparse,
>>> postZero = false, force = false), log id: 4e1f11e4
>>> 2012-10-11 12:47:32,428 INFO
>>>  [org.ovirt.engine.core.vdsbroker.irsbroker.CopyImageVDSCommand]
>>> (http--0.0.0.0-8080-1) [4473e7ae] --
>>> CopyImageVDSCommand::ExecuteIrsBrokerCommand: calling 'copyImage'
>>> with two new parameters: description and UUID
>>> 2012-10-11 12:47:32,430 INFO
>>>  [org.ovirt.engine.core.vdsbroker.irsbroker.CopyImageVDSCommand]
>>> (http--0.0.0.0-8080-1) [4473e7ae] -- copyImage parameters:
>>>                 sdUUID=48e1c5d2-9e46-4824-b45c-fd8d8fe6a85a
>>>                 spUUID=bfe850fc-14d0-4a06-a765-520a2b9e59e4
>>>                 vmGUID=00000000-0000-0000-0000-000000000000
>>>                 srcImageGUID=01f14d07-b519-4d2f-b573-b0f8a200cb3f
>>>                 srcVolUUID=f964947b-c88a-4c7e-aae1-7d8276e6eb23
>>>                 dstImageGUID=01f14d07-b519-4d2f-b573-b0f8a200cb3f
>>>                 dstVolUUID=f964947b-c88a-4c7e-aae1-7d8276e6eb23
>>>                 descr=
>>> 012-10-11 12:47:32,851 INFO
>>>  [org.ovirt.engine.core.vdsbroker.irsbroker.CopyImageVDSCommand]
>>> (http--0.0.0.0-8080-1) [4473e7ae] FINISH, CopyImageVDSCommand,
>>> return:
>>> 00000000-0000-0000-0000-000000000000, log id: 4e1f11e4
>>> 2012-10-11 12:47:32,880 INFO
>>>  [org.ovirt.engine.core.bll.EntityAsyncTask] (http--0.0.0.0-8080-1)
>>> [4473e7ae] EntityAsyncTask::Adding EntityMultiAsyncTasks object for
>>> entity
>>> f964947b-c88a-4c7e-aae1-7d8276e6eb23
>>> 2012-10-11 12:47:32,883 INFO
>>>  [org.ovirt.engine.core.bll.EntityMultiAsyncTasks]
>>> (http--0.0.0.0-8080-1) [4473e7ae] EntityMultiAsyncTasks::AttachTask:
>>> Attaching task
>>> 788f35e3-adc8-4c5b-82ff-9886b00a0965 to entity
>>> f964947b-c88a-4c7e-aae1-7d8276e6eb23.
>>> 2012-10-11 12:47:32,888 INFO
>>>  [org.ovirt.engine.core.bll.tasks.AsyncTaskUtils]
>>> (http--0.0.0.0-8080-1) [4473e7ae] Adding task
>>> 788f35e3-adc8-4c5b-82ff-9886b00a0965 to DataBase
>>> 2012-10-11 12:47:32,938 INFO
>>>  [org.ovirt.engine.core.bll.AsyncTaskManager] (http--0.0.0.0-8080-1)
>>> [4473e7ae] Adding task 788f35e3-adc8-4c5b-82ff-9886b00a0965 (Parent
>>> Command MoveOrCopyDisk, Parameters Type
>>> org.ovirt.engine.core.common.asynctasks.AsyncTaskParameters),
>>> polling hasn't started yet..
>>> 2012-10-11 12:47:32,997 INFO
>>>  [org.ovirt.engine.core.bll.MoveOrCopyDiskCommand]
>>> (http--0.0.0.0-8080-1) [4473e7ae] Lock freed to object EngineLock
>>> [exclusiveLocks= key:
>>> 01f14d07-b519-4d2f-b573-b0f8a200cb3f value: DISK
>>> , sharedLocks= key: 05ad22e4-a1c4-4caf-97ab-48127233ca24 value:
>>> TEMPLATE
>>>
>>>
>>>
>>> --
>>>
>>> Michael Pasternak
>>> RedHat, ENG-Virtualization R&D
>>>
> 
> 


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From ovirt at qip.ru  Thu Oct 11 13:18:04 2012
From: ovirt at qip.ru (ovirt at qip.ru)
Date: Thu, 11 Oct 2012 17:18:04 +0400
Subject: [Engine-devel]
 =?utf-8?q?jenkin=C2=ADs_ovirt-engine=5Fcreate=5Frp?=
 =?utf-8?q?m=C2=ADs_project?=
In-Reply-To: <1260984064.10518260.1349946029285.JavaMail.root@redhat.com>
References: <1260984064.10518260.1349946029285.JavaMail.root@redhat.com>
Message-ID: <bfa0c957cf7f3960c4faf254d435133d42433a3f@mail.qip.ru>

thanks, Eyal

but why there are no chages in #1605 build, where are all commits since 16.08.2012?
  

??? 11 ??? 2012 13:00:34 +0400, Eyal Edri <eedri at redhat.com> ???????:
> thanks for pointing that out!
> 
> for some reason the job was missing the poll scm value, and didn't have a trigger.
> 
> it will run run on every commit to ovirt-engine.
> 
> Eyal.
> 
> ----- Original Message -----
> > From: ovirt at qip.ru
> > To: engine-devel at ovirt.org
> > Sent: Tuesday, October 9, 2012 10:18:54 AM
> > Subject: [Engine-devel] jenkins ovirt-engine_create_rpms project
> > 
> > Hi,
> > 
> > last start of ovirt-engine_create_rpms job was more than one month
> > ago, may be it is possible to start ovirt-engine_create_rpms once a
> > day before publish_ovirt_rpms_nightly ?
> > 
> > 
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >

--


From rnori at redhat.com  Thu Oct 11 13:21:05 2012
From: rnori at redhat.com (Ravi Nori)
Date: Thu, 11 Oct 2012 15:21:05 +0200
Subject: [Engine-devel] "wipe after delete" Matching defaults from GUI
 to	Backend
In-Reply-To: <1486797178.8472794.1349824625385.JavaMail.root@redhat.com>
References: <1486797178.8472794.1349824625385.JavaMail.root@redhat.com>
Message-ID: <5076C7C1.6010405@redhat.com>

On 10/10/2012 01:17 AM, Daniel Erez wrote:
>
> ----- Original Message -----
>> From: "Ravi Nori" <rnori at redhat.com>
>> To: engine-devel at ovirt.org
>> Sent: Tuesday, October 9, 2012 6:40:56 PM
>> Subject: [Engine-devel] "wipe after delete" Matching defaults from GUI to	Backend
>>
>> I am working on the bug where the defaults values in the GUI for disk
>> actions don't correspond to the default values in the API/Backend.
>> For
>> example the "wipe after delete" flag defaults to true in the GUI but
>> false in the backend code. Default values are not sent from the
>> frontend
>> to the backend. Please refer to the bugzilla link
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=845466
>>
>> After discussing with Michael as to how to approach fixing this, we
>> think the best way to do it would be to fix it in the Backend class
>> businessentities.Disk by replacing primitives with reference types
>> and
>> forcing business logic in the class to set the default values to
>> match
>> the default values in the client.
>>
>> I would appreciate some feedback on this and also on what the default
>> values are for Disk operations on the GUI.
> GUI behavior is as follows:
> For File storage domains - WipeAfterDelete check-box is unchangeable and unchecked (false).
> For Block storage domains - WipeAfterDelete check-box is changeable and
> the default value is according to 'SANWipeAfterDelete' configuration value.
>
> I think you should simply utilize the same configuration value in
> REST or backend when creating a new disk.
>
>> Thanks
>>
>> Ravi
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
Thanks for the reply.

Here is my current implementation

I modified businessentities.BaseDisk class to change wipeAfterDelete to 
wrapper class (reference class) for boolean

     private Boolean wipeAfterDelete;

I also added default values for File and block storages
     private boolean wipeAfterDeleteFileStorageDomain = false;
     private boolean wipeAfterDeleteBlockStorageDomain =
Config.<Boolean>GetValue(ConfigValues.SANWipeAfterDelete);

The storage type determines which of the two default values is returned 
by BaseDisk when wipeAfterDelete is not set (is null)
     StorageType storageType = StorageType.UNKNOWN;

So isWipeAfterDeleteMethodLooks like this

     public boolean isWipeAfterDelete() {
         if (wipeAfterDelete == null) {
             return getDefaultIsWipeAfterDelete();
         }
         return wipeAfterDelete;
     }

     private boolean getDefaultIsWipeAfterDelete() {
         if(storageType.equals(StorageType.UNKNOWN)) {
             return false;
         }
         switch (storageType) {
             case ISCSI:
             case FCP:
                 return wipeAfterDeleteBlockStorageDomain;
             default:
                 return wipeAfterDeleteFileStorageDomain;
         }
     }

There is a new method isWipeAfterDeleteSet that will be used by commands 
to set the storage type to get the default wipeAfterDeleteFlag if 
wipeAfterDelete was not set.

     public boolean isWipeAfterDeleteSet() {
         return wipeAfterDelete != null;
     }

Now in bll.AddDiskCommand I modified executeVmCommand to add the following

         if(!getParameters().getDiskInfo().isWipeAfterDeleteSet()) {
             StorageType storageType = 
getStorageDomain().getstorage_type();
getParameters().getDiskInfo().setStorageType(storageType);
         }

This approach minimizes the impact of changes. So all commands 
interested in wipeAfterDelete flag based on storage type if 
wipeAfterDelete has not been set need to set the storageType before 
calling isWipeAfterDelete.

Please let me know if this is the solution conflicts with something you 
have been working on. All the existing code will work as it has been 
working, if wipeAfterDelete has not been set and storageType has not 
been set the method isWipeAfterDelete return false (like it was earlier)


From eedri at redhat.com  Thu Oct 11 14:37:00 2012
From: eedri at redhat.com (Eyal Edri)
Date: Thu, 11 Oct 2012 10:37:00 -0400 (EDT)
Subject: [Engine-devel]
 =?utf-8?q?jenkin=C2=ADs_ovirt-engine=5Fcreate=5Frp?=
 =?utf-8?q?m=C2=ADs_project?=
In-Reply-To: <bfa0c957cf7f3960c4faf254d435133d42433a3f@mail.qip.ru>
Message-ID: <2054758368.11010875.1349966220582.JavaMail.root@redhat.com>

not sure why jenkins doesn't show them,
but you can see from the rpm name ovirt-engine-3.1.0-3.20121011.git38912fc.fc17.noarch.rpm

it's built from the HEAD git SHA 38912fc89fb3acc8411e5d3332b2ab81e3cafc22

----- Original Message -----
> From: ovirt at qip.ru
> To: engine-devel at ovirt.org
> Sent: Thursday, October 11, 2012 3:18:04 PM
> Subject: Re: [Engine-devel] jenkin?s ovirt-engine_create_rpm?s project
> 
> thanks, Eyal
> 
> but why there are no chages in #1605 build, where are all commits
> since 16.08.2012?
>   
> 
> ??? 11 ??? 2012 13:00:34 +0400, Eyal Edri <eedri at redhat.com> ???????:
> > thanks for pointing that out!
> > 
> > for some reason the job was missing the poll scm value, and didn't
> > have a trigger.
> > 
> > it will run run on every commit to ovirt-engine.
> > 
> > Eyal.
> > 
> > ----- Original Message -----
> > > From: ovirt at qip.ru
> > > To: engine-devel at ovirt.org
> > > Sent: Tuesday, October 9, 2012 10:18:54 AM
> > > Subject: [Engine-devel] jenkins ovirt-engine_create_rpms project
> > > 
> > > Hi,
> > > 
> > > last start of ovirt-engine_create_rpms job was more than one
> > > month
> > > ago, may be it is possible to start ovirt-engine_create_rpms once
> > > a
> > > day before publish_ovirt_rpms_nightly ?
> > > 
> > > 
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > >
> 
> --
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>


From deadhorseconsulting at gmail.com  Thu Oct 11 17:00:02 2012
From: deadhorseconsulting at gmail.com (Dead Horse)
Date: Thu, 11 Oct 2012 12:00:02 -0500
Subject: [Engine-devel] Couple of small Feature Requests
Message-ID: <CAEWPe=r4gsVE-32gzWygh2SUf0Xr4V6xd5FDn6hnuP=NC22srA@mail.gmail.com>

Would like to make a couple of small feature requests.

1) Allow for the SPICE or VNC password to be set in the UI by admin's or
power users.
Benefit: (Assumes spice SSL has been disabled) allows user or admin to set
a password for access by a standalone remote session via vncviewer or
remote-viewer or the spice html5 implementation which is WIP, or standalone
HW thin client
- This may also assume that vdsm is running with SSL disabled as well to
have had vdsm make the neccesary changes to the qemu spice configuration

2) Display currently configured OR generated password and IP/Port for
either VNC or SPICE console of the VM within the PUP and Admin UI
Benefit: At the very least a standalone remote client can be used to
connect once the password and IP/PORT is known for spice or VNC
 - Currently VNC will display a dialog that shows the this info but it
would be more useful to have it displayed in the UI given proper privilege

3) Display the UUID of a VM in the Admin UI (similar to the how the disks
tab breaks down and shows DISK UUID mappings)
- Benefit: Easier for administrators to map UUID to VM config file data in
the data stores or export domains

- DHC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20121011/4517641d/attachment.html>

From derez at redhat.com  Thu Oct 11 20:56:34 2012
From: derez at redhat.com (Daniel Erez)
Date: Thu, 11 Oct 2012 16:56:34 -0400 (EDT)
Subject: [Engine-devel] VdcActionType.MoveOrCopyDisk
In-Reply-To: <5076AD34.3090607@redhat.com>
Message-ID: <798873251.47277.1349988994563.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Michael Pasternak" <mpastern at redhat.com>
> To: "Daniel Erez" <derez at redhat.com>
> Cc: "Einav Cohen" <ecohen at redhat.com>, "Ayal Baron" <abaron at redhat.com>, "Omer Frenkel" <ofrenkel at redhat.com>
> Sent: Thursday, October 11, 2012 1:27:48 PM
> Subject: Re: VdcActionType.MoveOrCopyDisk
> 
> On 10/11/2012 01:24 PM, Daniel Erez wrote:
> > From the log it seems that only one call to CopyImageVDSCommand
> > disk has been invoked.
> > Where do see it copying all template's disks?
> 
> later when i fetch all template's disks they all has new SD in
> storagedomains LIST.

I've tried it on my setup and checked the DB ('all_disks' view) - looks fine, only the selected disk has been copied.
How did you fetch the template's disks list (which query)?

> 
> > 
> > ----- Original Message -----
> >> From: "Michael Pasternak" <mpastern at redhat.com>
> >> To: "Ayal Baron" <abaron at redhat.com>, "Omer Frenkel"
> >> <ofrenkel at redhat.com>
> >> Cc: "Daniel Erez" <derez at redhat.com>, "Einav Cohen"
> >> <ecohen at redhat.com>
> >> Sent: Thursday, October 11, 2012 1:05:00 PM
> >> Subject: VdcActionType.MoveOrCopyDisk
> >>
> >> AFAIU (from derez) VdcActionType.MoveOrCopyDisk used to copy
> >> single
> >> disk
> >> to another storagedomain, but i see that it's actually copying all
> >> template's
> >> disks to this SD, not sure this expected behaviour ...
> >>
> >>
> >>
> >> 2012-10-11 12:47:32,144 INFO
> >>  [org.ovirt.engine.core.bll.MoveOrCopyDiskCommand]
> >> (http--0.0.0.0-8080-1) [4473e7ae] Lock Acquired to object
> >> EngineLock
> >> [exclusiveLocks= key:
> >> 01f14d07-b519-4d2f-b573-b0f8a200cb3f value: DISK
> >> , sharedLocks= key: 05ad22e4-a1c4-4caf-97ab-48127233ca24 value:
> >> TEMPLATE
> >> ]
> >> 2012-10-11 12:47:32,277 INFO
> >>  [org.ovirt.engine.core.bll.MoveOrCopyDiskCommand]
> >> (http--0.0.0.0-8080-1) [4473e7ae] Running command:
> >> MoveOrCopyDiskCommand internal: false.
> >> Entities affected :  ID: 01f14d07-b519-4d2f-b573-b0f8a200cb3f
> >> Type:
> >> Disk
> >> 2012-10-11 12:47:32,399 INFO
> >>  [org.ovirt.engine.core.bll.MoveOrCopyImageGroupCommand]
> >> (http--0.0.0.0-8080-1) [4473e7ae] Running command:
> >> MoveOrCopyImageGroupCommand
> >> internal: true. Entities affected :  ID:
> >> 47dd3e38-c252-4586-b180-afc8e8011df1 Type: Storage
> >> 2012-10-11 12:47:32,416 INFO
> >>  [org.ovirt.engine.core.vdsbroker.irsbroker.CopyImageVDSCommand]
> >> (http--0.0.0.0-8080-1) [4473e7ae] START, CopyImageVDSCommand(
> >> storagePoolId =
> >> bfe850fc-14d0-4a06-a765-520a2b9e59e4, ignoreFailoverLimit = false,
> >> compatabilityVersion = 3.0, storageDomainId =
> >> 48e1c5d2-9e46-4824-b45c-fd8d8fe6a85a, imageGroupId =
> >> 01f14d07-b519-4d2f-b573-b0f8a200cb3f, imageId =
> >> f964947b-c88a-4c7e-aae1-7d8276e6eb23, dstImageGroupId =
> >> 01f14d07-b519-4d2f-b573-b0f8a200cb3f, vmId =
> >> 00000000-0000-0000-0000-000000000000, dstImageId =
> >> f964947b-c88a-4c7e-aae1-7d8276e6eb23, imageDescription = ,
> >> dstStorageDomainId = 47dd3e38-c252-4586-b180-afc8e8011df1,
> >> copyVolumeType = SharedVol, volumeFormat = RAW, preallocate =
> >> Sparse,
> >> postZero = false, force = false), log id: 4e1f11e4
> >> 2012-10-11 12:47:32,428 INFO
> >>  [org.ovirt.engine.core.vdsbroker.irsbroker.CopyImageVDSCommand]
> >> (http--0.0.0.0-8080-1) [4473e7ae] --
> >> CopyImageVDSCommand::ExecuteIrsBrokerCommand: calling 'copyImage'
> >> with two new parameters: description and UUID
> >> 2012-10-11 12:47:32,430 INFO
> >>  [org.ovirt.engine.core.vdsbroker.irsbroker.CopyImageVDSCommand]
> >> (http--0.0.0.0-8080-1) [4473e7ae] -- copyImage parameters:
> >>                 sdUUID=48e1c5d2-9e46-4824-b45c-fd8d8fe6a85a
> >>                 spUUID=bfe850fc-14d0-4a06-a765-520a2b9e59e4
> >>                 vmGUID=00000000-0000-0000-0000-000000000000
> >>                 srcImageGUID=01f14d07-b519-4d2f-b573-b0f8a200cb3f
> >>                 srcVolUUID=f964947b-c88a-4c7e-aae1-7d8276e6eb23
> >>                 dstImageGUID=01f14d07-b519-4d2f-b573-b0f8a200cb3f
> >>                 dstVolUUID=f964947b-c88a-4c7e-aae1-7d8276e6eb23
> >>                 descr=
> >> 012-10-11 12:47:32,851 INFO
> >>  [org.ovirt.engine.core.vdsbroker.irsbroker.CopyImageVDSCommand]
> >> (http--0.0.0.0-8080-1) [4473e7ae] FINISH, CopyImageVDSCommand,
> >> return:
> >> 00000000-0000-0000-0000-000000000000, log id: 4e1f11e4
> >> 2012-10-11 12:47:32,880 INFO
> >>  [org.ovirt.engine.core.bll.EntityAsyncTask]
> >>  (http--0.0.0.0-8080-1)
> >> [4473e7ae] EntityAsyncTask::Adding EntityMultiAsyncTasks object
> >> for
> >> entity
> >> f964947b-c88a-4c7e-aae1-7d8276e6eb23
> >> 2012-10-11 12:47:32,883 INFO
> >>  [org.ovirt.engine.core.bll.EntityMultiAsyncTasks]
> >> (http--0.0.0.0-8080-1) [4473e7ae]
> >> EntityMultiAsyncTasks::AttachTask:
> >> Attaching task
> >> 788f35e3-adc8-4c5b-82ff-9886b00a0965 to entity
> >> f964947b-c88a-4c7e-aae1-7d8276e6eb23.
> >> 2012-10-11 12:47:32,888 INFO
> >>  [org.ovirt.engine.core.bll.tasks.AsyncTaskUtils]
> >> (http--0.0.0.0-8080-1) [4473e7ae] Adding task
> >> 788f35e3-adc8-4c5b-82ff-9886b00a0965 to DataBase
> >> 2012-10-11 12:47:32,938 INFO
> >>  [org.ovirt.engine.core.bll.AsyncTaskManager]
> >>  (http--0.0.0.0-8080-1)
> >> [4473e7ae] Adding task 788f35e3-adc8-4c5b-82ff-9886b00a0965
> >> (Parent
> >> Command MoveOrCopyDisk, Parameters Type
> >> org.ovirt.engine.core.common.asynctasks.AsyncTaskParameters),
> >> polling hasn't started yet..
> >> 2012-10-11 12:47:32,997 INFO
> >>  [org.ovirt.engine.core.bll.MoveOrCopyDiskCommand]
> >> (http--0.0.0.0-8080-1) [4473e7ae] Lock freed to object EngineLock
> >> [exclusiveLocks= key:
> >> 01f14d07-b519-4d2f-b573-b0f8a200cb3f value: DISK
> >> , sharedLocks= key: 05ad22e4-a1c4-4caf-97ab-48127233ca24 value:
> >> TEMPLATE
> >>
> >>
> >>
> >> --
> >>
> >> Michael Pasternak
> >> RedHat, ENG-Virtualization R&D
> >>
> 
> 
> --
> 
> Michael Pasternak
> RedHat, ENG-Virtualization R&D
> 


From derez at redhat.com  Thu Oct 11 21:28:53 2012
From: derez at redhat.com (Daniel Erez)
Date: Thu, 11 Oct 2012 17:28:53 -0400 (EDT)
Subject: [Engine-devel] "wipe after delete" Matching defaults from GUI
 to	Backend
In-Reply-To: <5076C7C1.6010405@redhat.com>
Message-ID: <445973371.72806.1349990933909.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Ravi Nori" <rnori at redhat.com>
> To: "Daniel Erez" <derez at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Thursday, October 11, 2012 3:21:05 PM
> Subject: Re: [Engine-devel] "wipe after delete" Matching defaults from GUI to	Backend
> 
> On 10/10/2012 01:17 AM, Daniel Erez wrote:
> >
> > ----- Original Message -----
> >> From: "Ravi Nori" <rnori at redhat.com>
> >> To: engine-devel at ovirt.org
> >> Sent: Tuesday, October 9, 2012 6:40:56 PM
> >> Subject: [Engine-devel] "wipe after delete" Matching defaults from
> >> GUI to	Backend
> >>
> >> I am working on the bug where the defaults values in the GUI for
> >> disk
> >> actions don't correspond to the default values in the API/Backend.
> >> For
> >> example the "wipe after delete" flag defaults to true in the GUI
> >> but
> >> false in the backend code. Default values are not sent from the
> >> frontend
> >> to the backend. Please refer to the bugzilla link
> >>
> >> https://bugzilla.redhat.com/show_bug.cgi?id=845466
> >>
> >> After discussing with Michael as to how to approach fixing this,
> >> we
> >> think the best way to do it would be to fix it in the Backend
> >> class
> >> businessentities.Disk by replacing primitives with reference types
> >> and
> >> forcing business logic in the class to set the default values to
> >> match
> >> the default values in the client.
> >>
> >> I would appreciate some feedback on this and also on what the
> >> default
> >> values are for Disk operations on the GUI.
> > GUI behavior is as follows:
> > For File storage domains - WipeAfterDelete check-box is
> > unchangeable and unchecked (false).
> > For Block storage domains - WipeAfterDelete check-box is changeable
> > and
> > the default value is according to 'SANWipeAfterDelete'
> > configuration value.
> >
> > I think you should simply utilize the same configuration value in
> > REST or backend when creating a new disk.
> >
> >> Thanks
> >>
> >> Ravi
> >> _______________________________________________
> >> Engine-devel mailing list
> >> Engine-devel at ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>
> Thanks for the reply.
> 
> Here is my current implementation
> 
> I modified businessentities.BaseDisk class to change wipeAfterDelete
> to
> wrapper class (reference class) for boolean
> 
>      private Boolean wipeAfterDelete;
> 
> I also added default values for File and block storages
>      private boolean wipeAfterDeleteFileStorageDomain = false;
>      private boolean wipeAfterDeleteBlockStorageDomain =
> Config.<Boolean>GetValue(ConfigValues.SANWipeAfterDelete);
> 
> The storage type determines which of the two default values is
> returned
> by BaseDisk when wipeAfterDelete is not set (is null)
>      StorageType storageType = StorageType.UNKNOWN;
> 
> So isWipeAfterDeleteMethodLooks like this
> 
>      public boolean isWipeAfterDelete() {
>          if (wipeAfterDelete == null) {
>              return getDefaultIsWipeAfterDelete();
>          }
>          return wipeAfterDelete;
>      }
> 
>      private boolean getDefaultIsWipeAfterDelete() {
>          if(storageType.equals(StorageType.UNKNOWN)) {
>              return false;
>          }
>          switch (storageType) {
>              case ISCSI:
>              case FCP:
>                  return wipeAfterDeleteBlockStorageDomain;
>              default:
>                  return wipeAfterDeleteFileStorageDomain;
>          }
>      }
> 
> There is a new method isWipeAfterDeleteSet that will be used by
> commands
> to set the storage type to get the default wipeAfterDeleteFlag if
> wipeAfterDelete was not set.
> 
>      public boolean isWipeAfterDeleteSet() {
>          return wipeAfterDelete != null;
>      }
> 
> Now in bll.AddDiskCommand I modified executeVmCommand to add the
> following
> 
>          if(!getParameters().getDiskInfo().isWipeAfterDeleteSet()) {
>              StorageType storageType =
> getStorageDomain().getstorage_type();
> getParameters().getDiskInfo().setStorageType(storageType);
>          }
> 
> This approach minimizes the impact of changes. So all commands
> interested in wipeAfterDelete flag based on storage type if
> wipeAfterDelete has not been set need to set the storageType before
> calling isWipeAfterDelete.
> 
> Please let me know if this is the solution conflicts with something
> you
> have been working on. All the existing code will work as it has been
> working, if wipeAfterDelete has not been set and storageType has not
> been set the method isWipeAfterDelete return false (like it was
> earlier)
> 


Calling 'Config.<?> GetValue' in a business entity could be problematic in the UI since 
only the backend can invoke it (business entities are common for the backend and the UI
which means that both may instantiate/manipulate them).
We use GWT RPC for serializing/deserializing these business entities,
thus we usually can't reference non plain java objects (or use some tweaks/tricks if applicable).
Try to check the UI behavior after the new changes and let me know...
[as an alternative, you can probably get 'SANWipeAfterDelete' config value from REST code (or backend)].




From iheim at redhat.com  Thu Oct 11 23:50:42 2012
From: iheim at redhat.com (Itamar Heim)
Date: Thu, 11 Oct 2012 19:50:42 -0400
Subject: [Engine-devel] "wipe after delete" Matching defaults from GUI
 to	Backend
In-Reply-To: <445973371.72806.1349990933909.JavaMail.root@redhat.com>
References: <445973371.72806.1349990933909.JavaMail.root@redhat.com>
Message-ID: <50775B52.8000301@redhat.com>

On 10/11/2012 05:28 PM, Daniel Erez wrote:
>
>
> ----- Original Message -----
>> From: "Ravi Nori" <rnori at redhat.com>
>> To: "Daniel Erez" <derez at redhat.com>
>> Cc: engine-devel at ovirt.org
>> Sent: Thursday, October 11, 2012 3:21:05 PM
>> Subject: Re: [Engine-devel] "wipe after delete" Matching defaults from GUI to	Backend
>>
>> On 10/10/2012 01:17 AM, Daniel Erez wrote:
>>>
>>> ----- Original Message -----
>>>> From: "Ravi Nori" <rnori at redhat.com>
>>>> To: engine-devel at ovirt.org
>>>> Sent: Tuesday, October 9, 2012 6:40:56 PM
>>>> Subject: [Engine-devel] "wipe after delete" Matching defaults from
>>>> GUI to	Backend
>>>>
>>>> I am working on the bug where the defaults values in the GUI for
>>>> disk
>>>> actions don't correspond to the default values in the API/Backend.
>>>> For
>>>> example the "wipe after delete" flag defaults to true in the GUI
>>>> but
>>>> false in the backend code. Default values are not sent from the
>>>> frontend
>>>> to the backend. Please refer to the bugzilla link
>>>>
>>>> https://bugzilla.redhat.com/show_bug.cgi?id=845466
>>>>
>>>> After discussing with Michael as to how to approach fixing this,
>>>> we
>>>> think the best way to do it would be to fix it in the Backend
>>>> class
>>>> businessentities.Disk by replacing primitives with reference types
>>>> and
>>>> forcing business logic in the class to set the default values to
>>>> match
>>>> the default values in the client.
>>>>
>>>> I would appreciate some feedback on this and also on what the
>>>> default
>>>> values are for Disk operations on the GUI.
>>> GUI behavior is as follows:
>>> For File storage domains - WipeAfterDelete check-box is
>>> unchangeable and unchecked (false).
>>> For Block storage domains - WipeAfterDelete check-box is changeable
>>> and
>>> the default value is according to 'SANWipeAfterDelete'
>>> configuration value.
>>>
>>> I think you should simply utilize the same configuration value in
>>> REST or backend when creating a new disk.
>>>
>>>> Thanks
>>>>
>>>> Ravi
>>>> _______________________________________________
>>>> Engine-devel mailing list
>>>> Engine-devel at ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>
>> Thanks for the reply.
>>
>> Here is my current implementation
>>
>> I modified businessentities.BaseDisk class to change wipeAfterDelete
>> to
>> wrapper class (reference class) for boolean
>>
>>       private Boolean wipeAfterDelete;
>>
>> I also added default values for File and block storages
>>       private boolean wipeAfterDeleteFileStorageDomain = false;
>>       private boolean wipeAfterDeleteBlockStorageDomain =
>> Config.<Boolean>GetValue(ConfigValues.SANWipeAfterDelete);
>>
>> The storage type determines which of the two default values is
>> returned
>> by BaseDisk when wipeAfterDelete is not set (is null)
>>       StorageType storageType = StorageType.UNKNOWN;
>>
>> So isWipeAfterDeleteMethodLooks like this
>>
>>       public boolean isWipeAfterDelete() {
>>           if (wipeAfterDelete == null) {
>>               return getDefaultIsWipeAfterDelete();
>>           }
>>           return wipeAfterDelete;
>>       }
>>
>>       private boolean getDefaultIsWipeAfterDelete() {
>>           if(storageType.equals(StorageType.UNKNOWN)) {
>>               return false;
>>           }
>>           switch (storageType) {
>>               case ISCSI:
>>               case FCP:
>>                   return wipeAfterDeleteBlockStorageDomain;
>>               default:
>>                   return wipeAfterDeleteFileStorageDomain;
>>           }
>>       }
>>
>> There is a new method isWipeAfterDeleteSet that will be used by
>> commands
>> to set the storage type to get the default wipeAfterDeleteFlag if
>> wipeAfterDelete was not set.
>>
>>       public boolean isWipeAfterDeleteSet() {
>>           return wipeAfterDelete != null;
>>       }
>>
>> Now in bll.AddDiskCommand I modified executeVmCommand to add the
>> following
>>
>>           if(!getParameters().getDiskInfo().isWipeAfterDeleteSet()) {
>>               StorageType storageType =
>> getStorageDomain().getstorage_type();
>> getParameters().getDiskInfo().setStorageType(storageType);
>>           }
>>
>> This approach minimizes the impact of changes. So all commands
>> interested in wipeAfterDelete flag based on storage type if
>> wipeAfterDelete has not been set need to set the storageType before
>> calling isWipeAfterDelete.
>>
>> Please let me know if this is the solution conflicts with something
>> you
>> have been working on. All the existing code will work as it has been
>> working, if wipeAfterDelete has not been set and storageType has not
>> been set the method isWipeAfterDelete return false (like it was
>> earlier)
>>
>
>
> Calling 'Config.<?> GetValue' in a business entity could be problematic in the UI since
> only the backend can invoke it (business entities are common for the backend and the UI
> which means that both may instantiate/manipulate them).
> We use GWT RPC for serializing/deserializing these business entities,
> thus we usually can't reference non plain java objects (or use some tweaks/tricks if applicable).
> Try to check the UI behavior after the new changes and let me know...
> [as an alternative, you can probably get 'SANWipeAfterDelete' config value from REST code (or backend)].

clients (UI/API) can only call the ConfigurationValues enum, and should 
use the query for it (gui has this already of course, just look it up)


From vszocs at redhat.com  Fri Oct 12 11:23:00 2012
From: vszocs at redhat.com (Vojtech Szocs)
Date: Fri, 12 Oct 2012 07:23:00 -0400 (EDT)
Subject: [Engine-devel] oVirt UI Plugins Presentation: PDF slides
In-Reply-To: <50752548.4050802@redhat.com>
Message-ID: <229789455.7641348.1350040980085.JavaMail.root@redhat.com>

Thanks Itamar!

Please find my comments inline:

> 1. you are using internal entities ("VDS") - the ui API must only use
>    entities and actions which match the REST API entities/actions.
>    or to begin with, make all these entities share IEntity, and just
>    pass the IEntity.EntityId property for them to the plugin).

You are right, "VDS" (org.ovirt.engine.core.common.businessentities.VDS) is indeed internal business entity, currently shared between backend and frontend.

However, in slide "new application event, part 3", information about currently selected hosts (list of VDS) is not passed to plugins whatsoever - the slide only mentions that the contextObject passed to plugins "could carry data about hosts that were activated" (i.e. hosts currently selected after performing activate command).

As you suggested, the contextObject is intended to carry Engine REST API-like representations of business entities, preferably using JSON notation for seamless integration with plugin (JavaScript) code. We'll most likely start with simple entity representations that only contain entity ID, and extend them later on (as you suggested). In fact, this is what I'm working on right now, as part of "custom context-sensitive button / menu item" plugin API feature :)

> 2. slides 21-25
>    iiuc, these are part of the plugin api infrastrcture, not of a
>    sample plugin. i think a sample, simple, javascript plugin git repo
>    would be great (like we have sample hooks for vdsm).

That's correct, these slides were meant as the final part of the presentation ("Tips for implementing new plugin features"), they are not related to the previous ("Tutorial on writing simple plugin") part. The goal of these slides is to give community deeper insight on how to leverage existing plugin infrastructure to implement new features on top of it (new API function, new event to be consumed by plugins).

Sample plugin git repo - sounds great! We could have one sample plugin per feature of plugin infrastructure, e.g. sample plugin that shows how to add main tab, etc. Very good idea!

Could this be part of oVirt git repo (git://gerrit.ovirt.org/ovirt-engine) or should we use some other repo?

> 3. nit(?): the event you fire in the sample is not HostActivated,
>    rather HostActivateRequest? i.e., need to distinguish between a
>    request for an action, to a real status change of an object (which
>    would be a change for a host entity in the grid from one status to a
>    another status)?

"HostActivated" is just an example of how plugin callback (event handler) function can be called, in the situation when user clicks "Activate Host(s)" and plugins want to hook to this "event".

The code presented on slides first invokes default (activate host) behavior [without asking plugins], and then gives all plugins the chance to do something in addition to that (through "HostActivated" event handler function).

"HostActivateRequest" - could be implemented as well, IIUC - plugins would be asked if it's OK to proceed with host activation. This would be a separate plugin callback (event handler) function. Please correct me if I didn't understand your point correctly.

Regards,
Vojtech


----- Original Message -----
From: "Itamar Heim" <iheim at redhat.com>
To: "Vojtech Szocs" <vszocs at redhat.com>
Cc: "engine-devel" <engine-devel at ovirt.org>
Sent: Wednesday, October 10, 2012 9:35:36 AM
Subject: Re: [Engine-devel] oVirt UI Plugins Presentation: PDF slides

On 10/09/2012 12:39 PM, Vojtech Szocs wrote:
> Hi guys,
>
> please find the slides for today's UI Plugins presentation attached to this email.
>
> Regards,
> Vojtech
>
>
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>

great deck!

few comments/questions:
1. you are using internal entities ("VDS") - the ui API must only use
    entities and actions which match the REST API entities/actions.
    or to begin with, make all these entities share IEntity, and just
    pass the IEntity.EntityId property for them to the plugin).
2. slides 21-25
    iiuc, these are part of the plugin api infrastrcture, not of a
    sample plugin. i think a sample, simple, javascript plugin git repo
    would be great (like we have sample hooks for vdsm).
3. nit(?): the event you fire in the sample is not HostActivated,
    rather HostActivateRequest? i.e., need to distinguish between a
    request for an action, to a real status change of an object (which
    would be a change for a host entity in the grid from one status to a
    another status)?


From vszocs at redhat.com  Fri Oct 12 12:14:17 2012
From: vszocs at redhat.com (Vojtech Szocs)
Date: Fri, 12 Oct 2012 08:14:17 -0400 (EDT)
Subject: [Engine-devel] UI Plugins presentation at oVirt Workshop 2012
	(Barcelona)
In-Reply-To: <1810675976.7649661.1350043737584.JavaMail.root@redhat.com>
Message-ID: <699906950.7650594.1350044057826.JavaMail.root@redhat.com>

Hi guys,

I'll be giving a session about UI Plugins at oVirt Workshop, which takes place in Barcelona, November 7-9.

http://events.linuxfoundation.org/events/kvm-forum

I'll be more than happy to meet and chat with anyone interested in UI Plugins or oVirt Frontend in general. I'm also open to working together on hacking around UI Plugins to prototype features you're interested in.

Cheers,
Vojtech


From vszocs at redhat.com  Fri Oct 12 13:03:31 2012
From: vszocs at redhat.com (Vojtech Szocs)
Date: Fri, 12 Oct 2012 09:03:31 -0400 (EDT)
Subject: [Engine-devel] Update on UI Plugins: context-sensitive button API
	preview
In-Reply-To: <562224602.7650818.1350044141235.JavaMail.root@redhat.com>
Message-ID: <1031952541.7675796.1350047011301.JavaMail.root@redhat.com>

Hi guys, 

I've been working on implementing "custom context-sensitive button / menu item" plugin API feature recently, and wanted to share some code with you. 

Here's a sample code that adds "Do something with selected host(s)" button to Hosts main tab data grid: 

api.register({ 
UiInit: function() { 

api. addMainTabActionButton ('Host', 'Do something with selected host(s)', { 

onClick : function() { 
// 'arguments' contain host entities currently selected 
window.alert(arguments.length + ' host(s) selected'); 
window.alert('first selected host ID = ' + arguments[0].entityId); 

// Open new popup window 
// In future, we might use "dialog UI" plugin API here 
window.open('http://example.com', '_blank'); 
}, 

isEnabled : function() { 
// 'true' means the button is enabled and clickable (default) 
// 'false' means the button is disabled and non-clickable 

// Enable button only when the number of selected items > 0 
return arguments.length > 0; 
}, 

isAccessible : function() { 
// 'true' means the button is visible (default) 
// 'false' means the button is hidden 
return true; 
} 

}); 

} 
}); 

The signature of addMainTabActionButton plugin API function is following: 

addMainTabActionButton(entityTypeName, label, actionButtonInterface) 

entityTypeName indicates which main tab the button should be added to, e.g. "Host" for Host main tab. [Quick question for NetApp guys: do we want to support all main tab entity types?] 

label is the title displayed on the button. 

actionButtonInterface represents an object that "implements the button interface" by declaring its functions: onClick , isEnabled , isAccessible . Since JavaScript language uses different techniques and syntax to achieve OOP programming model, I've decided to keep things simple and stay with plain objects containing functions. While some JavaScript guru could advocate different approach, from WebAdmin vs. plugin integration perspective, the above mentioned approach is the easiest way. I'm also interested to hear your opinion on this. 

All functions of actionButtonInterface receive currently selected item(s) as function arguments. Within a JavaScript function, "arguments" represents an implicit array of its arguments. 

For now, WebAdmin will pass simple JSON-like objects to these functions, for example: 

{ entityId: "<whatever>" } 

In future, we can extend or modify this concept to match the contract of various oVirt REST API entities. 

This feature will be part of UI Plugins PoC rev.6, which should come out next week. 

Regards, 
Vojtech 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20121012/933a084d/attachment.html>

From djasa at redhat.com  Fri Oct 12 14:42:28 2012
From: djasa at redhat.com (David =?UTF-8?Q?Ja=C5=A1a?=)
Date: Fri, 12 Oct 2012 16:42:28 +0200
Subject: [Engine-devel] Couple of small Feature Requests
In-Reply-To: <CAEWPe=r4gsVE-32gzWygh2SUf0Xr4V6xd5FDn6hnuP=NC22srA@mail.gmail.com>
References: <CAEWPe=r4gsVE-32gzWygh2SUf0Xr4V6xd5FDn6hnuP=NC22srA@mail.gmail.com>
Message-ID: <1350052948.3419.8.camel@dhcp-29-7.brq.redhat.com>

Hi,

Dead Horse p??e v ?t 11. 10. 2012 v 12:00 -0500:
> Would like to make a couple of small feature requests.
> 
> 1) Allow for the SPICE or VNC password to be set in the UI by admin's
> or power users.
> Benefit: (Assumes spice SSL has been disabled) allows user or admin to
> set a password for access by a standalone remote session via vncviewer
> or remote-viewer or the spice html5 implementation which is WIP, or
> standalone HW thin client
> - This may also assume that vdsm is running with SSL disabled as well
> to have had vdsm make the neccesary changes to the qemu spice
> configuration

Drawback: users can choose repetitive and/or weak passwords. Generating
a new random password for each connection is the best thing from
security POV in my opinion.

> 
> 2) Display currently configured OR generated password and IP/Port for
> either VNC or SPICE console of the VM within the PUP and Admin UI
> Benefit: At the very least a standalone remote client can be used to
> connect once the password and IP/PORT is known for spice or VNC 
>  - Currently VNC will display a dialog that shows the this info but it
> would be more useful to have it displayed in the UI given proper
> privilege

https://bugzilla.redhat.com/show_bug.cgi?id=843397
https://bugzilla.redhat.com/show_bug.cgi?id=843410

> 
> 3) Display the UUID of a VM in the Admin UI (similar to the how the
> disks tab breaks down and shows DISK UUID mappings)
> - Benefit: Easier for administrators to map UUID to VM config file
> data in the data stores or export domains

IMO full uuid should be displayed in General subtab only because it's
too long to have it as a column.

It would be nice to see it in a column though in some shortened form
because it could probably enable relaxing of
unique-name-of-VM-in-whole-setup restriction.

David

> 
> - DHC
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel

-- 

David Ja?a, RHCE

SPICE QE based in Brno
GPG Key:     22C33E24 
Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24





From rnori at redhat.com  Fri Oct 12 19:25:33 2012
From: rnori at redhat.com (Ravi Nori)
Date: Fri, 12 Oct 2012 15:25:33 -0400
Subject: [Engine-devel] "wipe after delete" Matching defaults from GUI
 to	Backend
In-Reply-To: <50775B52.8000301@redhat.com>
References: <445973371.72806.1349990933909.JavaMail.root@redhat.com>
	<50775B52.8000301@redhat.com>
Message-ID: <50786EAD.8040707@redhat.com>

On 10/11/2012 07:50 PM, Itamar Heim wrote:
> On 10/11/2012 05:28 PM, Daniel Erez wrote:
>>
>>
>> ----- Original Message -----
>>> From: "Ravi Nori" <rnori at redhat.com>
>>> To: "Daniel Erez" <derez at redhat.com>
>>> Cc: engine-devel at ovirt.org
>>> Sent: Thursday, October 11, 2012 3:21:05 PM
>>> Subject: Re: [Engine-devel] "wipe after delete" Matching defaults 
>>> from GUI to    Backend
>>>
>>> On 10/10/2012 01:17 AM, Daniel Erez wrote:
>>>>
>>>> ----- Original Message -----
>>>>> From: "Ravi Nori" <rnori at redhat.com>
>>>>> To: engine-devel at ovirt.org
>>>>> Sent: Tuesday, October 9, 2012 6:40:56 PM
>>>>> Subject: [Engine-devel] "wipe after delete" Matching defaults from
>>>>> GUI to    Backend
>>>>>
>>>>> I am working on the bug where the defaults values in the GUI for
>>>>> disk
>>>>> actions don't correspond to the default values in the API/Backend.
>>>>> For
>>>>> example the "wipe after delete" flag defaults to true in the GUI
>>>>> but
>>>>> false in the backend code. Default values are not sent from the
>>>>> frontend
>>>>> to the backend. Please refer to the bugzilla link
>>>>>
>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=845466
>>>>>
>>>>> After discussing with Michael as to how to approach fixing this,
>>>>> we
>>>>> think the best way to do it would be to fix it in the Backend
>>>>> class
>>>>> businessentities.Disk by replacing primitives with reference types
>>>>> and
>>>>> forcing business logic in the class to set the default values to
>>>>> match
>>>>> the default values in the client.
>>>>>
>>>>> I would appreciate some feedback on this and also on what the
>>>>> default
>>>>> values are for Disk operations on the GUI.
>>>> GUI behavior is as follows:
>>>> For File storage domains - WipeAfterDelete check-box is
>>>> unchangeable and unchecked (false).
>>>> For Block storage domains - WipeAfterDelete check-box is changeable
>>>> and
>>>> the default value is according to 'SANWipeAfterDelete'
>>>> configuration value.
>>>>
>>>> I think you should simply utilize the same configuration value in
>>>> REST or backend when creating a new disk.
>>>>
>>>>> Thanks
>>>>>
>>>>> Ravi
>>>>> _______________________________________________
>>>>> Engine-devel mailing list
>>>>> Engine-devel at ovirt.org
>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>
>>> Thanks for the reply.
>>>
>>> Here is my current implementation
>>>
>>> I modified businessentities.BaseDisk class to change wipeAfterDelete
>>> to
>>> wrapper class (reference class) for boolean
>>>
>>>       private Boolean wipeAfterDelete;
>>>
>>> I also added default values for File and block storages
>>>       private boolean wipeAfterDeleteFileStorageDomain = false;
>>>       private boolean wipeAfterDeleteBlockStorageDomain =
>>> Config.<Boolean>GetValue(ConfigValues.SANWipeAfterDelete);
>>>
>>> The storage type determines which of the two default values is
>>> returned
>>> by BaseDisk when wipeAfterDelete is not set (is null)
>>>       StorageType storageType = StorageType.UNKNOWN;
>>>
>>> So isWipeAfterDeleteMethodLooks like this
>>>
>>>       public boolean isWipeAfterDelete() {
>>>           if (wipeAfterDelete == null) {
>>>               return getDefaultIsWipeAfterDelete();
>>>           }
>>>           return wipeAfterDelete;
>>>       }
>>>
>>>       private boolean getDefaultIsWipeAfterDelete() {
>>>           if(storageType.equals(StorageType.UNKNOWN)) {
>>>               return false;
>>>           }
>>>           switch (storageType) {
>>>               case ISCSI:
>>>               case FCP:
>>>                   return wipeAfterDeleteBlockStorageDomain;
>>>               default:
>>>                   return wipeAfterDeleteFileStorageDomain;
>>>           }
>>>       }
>>>
>>> There is a new method isWipeAfterDeleteSet that will be used by
>>> commands
>>> to set the storage type to get the default wipeAfterDeleteFlag if
>>> wipeAfterDelete was not set.
>>>
>>>       public boolean isWipeAfterDeleteSet() {
>>>           return wipeAfterDelete != null;
>>>       }
>>>
>>> Now in bll.AddDiskCommand I modified executeVmCommand to add the
>>> following
>>>
>>> if(!getParameters().getDiskInfo().isWipeAfterDeleteSet()) {
>>>               StorageType storageType =
>>> getStorageDomain().getstorage_type();
>>> getParameters().getDiskInfo().setStorageType(storageType);
>>>           }
>>>
>>> This approach minimizes the impact of changes. So all commands
>>> interested in wipeAfterDelete flag based on storage type if
>>> wipeAfterDelete has not been set need to set the storageType before
>>> calling isWipeAfterDelete.
>>>
>>> Please let me know if this is the solution conflicts with something
>>> you
>>> have been working on. All the existing code will work as it has been
>>> working, if wipeAfterDelete has not been set and storageType has not
>>> been set the method isWipeAfterDelete return false (like it was
>>> earlier)
>>>
>>
>>
>> Calling 'Config.<?> GetValue' in a business entity could be 
>> problematic in the UI since
>> only the backend can invoke it (business entities are common for the 
>> backend and the UI
>> which means that both may instantiate/manipulate them).
>> We use GWT RPC for serializing/deserializing these business entities,
>> thus we usually can't reference non plain java objects (or use some 
>> tweaks/tricks if applicable).
>> Try to check the UI behavior after the new changes and let me know...
>> [as an alternative, you can probably get 'SANWipeAfterDelete' config 
>> value from REST code (or backend)].
>
> clients (UI/API) can only call the ConfigurationValues enum, and 
> should use the query for it (gui has this already of course, just look 
> it up)
Yes it is going to be a problem with the UI, I will work on an 
alternative. Since this method will be called from both backend and 
frontend code, I think it is best not to have the logic to extract the 
default value in the BaseDisk class. I am leaning towards the following 
implementation, please let me know your thoughts. I also took a look at 
ConfigurationValues but I thinks the below works best

The only change in the BaseDisk class is changing the reference type for 
wipeAfterDelete flag and the addition of a new method

     public boolean isWipeAfterDeleteSet() {
         return wipeAfterDelete != null;
     }

and change in isWipeAfterDelete method

     public boolean isWipeAfterDelete() {
         if (isWipeAfterDeleteSet()) {
             return wipeAfterDelete;
         }
         return false;
     }

The backend handles the logic when wipeAfterDelete flag is not set. So 
in AddDiskCommand executeVmCommand method we check if the flag is set, 
otherwise we get the storage type and get the default value using the 
new Utility class WipeAfterDeleteUtils

        if(!getParameters().getDiskInfo().isWipeAfterDeleteSet()) {
             StorageType storageType = getStorageDomain().getstorage_type();
getParameters().getDiskInfo().setWipeAfterDelete(WipeAfterDeleteUtils.getDefaultWipeAfterDeleteFlag(storageType));
         }

and the Utility class is a very simple class that extracts the default 
value based on the storagetype

public class WipeAfterDeleteUtils {

     static Boolean wipeAfterDeleteBlockStorageDomain;

     static boolean wipeAfterDeleteFileStorageDomain = false;

     public static synchronized boolean 
getDefaultWipeAfterDeleteFlag(final StorageType storageType) {
         if(storageType.isBlockDomain()) {
             if(wipeAfterDeleteBlockStorageDomain == null) {
                     wipeAfterDeleteBlockStorageDomain =
Config.<Boolean>GetValue(ConfigValues.SANWipeAfterDelete);
             }
             return wipeAfterDeleteBlockStorageDomain;
         }
         if(storageType.isFileDomain()) {
             return wipeAfterDeleteFileStorageDomain;
         }
         return false;
     }
}



From abaron at redhat.com  Sat Oct 13 20:47:30 2012
From: abaron at redhat.com (Ayal Baron)
Date: Sat, 13 Oct 2012 16:47:30 -0400 (EDT)
Subject: [Engine-devel] "wipe after delete" Matching defaults from GUI
 to	Backend
In-Reply-To: <50786EAD.8040707@redhat.com>
Message-ID: <1107879448.10287851.1350161250271.JavaMail.root@redhat.com>

Please send a WIP patch to gerrit for easier review.

----- Original Message -----
> On 10/11/2012 07:50 PM, Itamar Heim wrote:
> > On 10/11/2012 05:28 PM, Daniel Erez wrote:
> >>
> >>
> >> ----- Original Message -----
> >>> From: "Ravi Nori" <rnori at redhat.com>
> >>> To: "Daniel Erez" <derez at redhat.com>
> >>> Cc: engine-devel at ovirt.org
> >>> Sent: Thursday, October 11, 2012 3:21:05 PM
> >>> Subject: Re: [Engine-devel] "wipe after delete" Matching defaults
> >>> from GUI to    Backend
> >>>
> >>> On 10/10/2012 01:17 AM, Daniel Erez wrote:
> >>>>
> >>>> ----- Original Message -----
> >>>>> From: "Ravi Nori" <rnori at redhat.com>
> >>>>> To: engine-devel at ovirt.org
> >>>>> Sent: Tuesday, October 9, 2012 6:40:56 PM
> >>>>> Subject: [Engine-devel] "wipe after delete" Matching defaults
> >>>>> from
> >>>>> GUI to    Backend
> >>>>>
> >>>>> I am working on the bug where the defaults values in the GUI
> >>>>> for
> >>>>> disk
> >>>>> actions don't correspond to the default values in the
> >>>>> API/Backend.
> >>>>> For
> >>>>> example the "wipe after delete" flag defaults to true in the
> >>>>> GUI
> >>>>> but
> >>>>> false in the backend code. Default values are not sent from the
> >>>>> frontend
> >>>>> to the backend. Please refer to the bugzilla link
> >>>>>
> >>>>> https://bugzilla.redhat.com/show_bug.cgi?id=845466
> >>>>>
> >>>>> After discussing with Michael as to how to approach fixing
> >>>>> this,
> >>>>> we
> >>>>> think the best way to do it would be to fix it in the Backend
> >>>>> class
> >>>>> businessentities.Disk by replacing primitives with reference
> >>>>> types
> >>>>> and
> >>>>> forcing business logic in the class to set the default values
> >>>>> to
> >>>>> match
> >>>>> the default values in the client.
> >>>>>
> >>>>> I would appreciate some feedback on this and also on what the
> >>>>> default
> >>>>> values are for Disk operations on the GUI.
> >>>> GUI behavior is as follows:
> >>>> For File storage domains - WipeAfterDelete check-box is
> >>>> unchangeable and unchecked (false).
> >>>> For Block storage domains - WipeAfterDelete check-box is
> >>>> changeable
> >>>> and
> >>>> the default value is according to 'SANWipeAfterDelete'
> >>>> configuration value.
> >>>>
> >>>> I think you should simply utilize the same configuration value
> >>>> in
> >>>> REST or backend when creating a new disk.
> >>>>
> >>>>> Thanks
> >>>>>
> >>>>> Ravi
> >>>>> _______________________________________________
> >>>>> Engine-devel mailing list
> >>>>> Engine-devel at ovirt.org
> >>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>>>>
> >>> Thanks for the reply.
> >>>
> >>> Here is my current implementation
> >>>
> >>> I modified businessentities.BaseDisk class to change
> >>> wipeAfterDelete
> >>> to
> >>> wrapper class (reference class) for boolean
> >>>
> >>>       private Boolean wipeAfterDelete;
> >>>
> >>> I also added default values for File and block storages
> >>>       private boolean wipeAfterDeleteFileStorageDomain = false;
> >>>       private boolean wipeAfterDeleteBlockStorageDomain =
> >>> Config.<Boolean>GetValue(ConfigValues.SANWipeAfterDelete);
> >>>
> >>> The storage type determines which of the two default values is
> >>> returned
> >>> by BaseDisk when wipeAfterDelete is not set (is null)
> >>>       StorageType storageType = StorageType.UNKNOWN;
> >>>
> >>> So isWipeAfterDeleteMethodLooks like this
> >>>
> >>>       public boolean isWipeAfterDelete() {
> >>>           if (wipeAfterDelete == null) {
> >>>               return getDefaultIsWipeAfterDelete();
> >>>           }
> >>>           return wipeAfterDelete;
> >>>       }
> >>>
> >>>       private boolean getDefaultIsWipeAfterDelete() {
> >>>           if(storageType.equals(StorageType.UNKNOWN)) {
> >>>               return false;
> >>>           }
> >>>           switch (storageType) {
> >>>               case ISCSI:
> >>>               case FCP:
> >>>                   return wipeAfterDeleteBlockStorageDomain;
> >>>               default:
> >>>                   return wipeAfterDeleteFileStorageDomain;
> >>>           }
> >>>       }
> >>>
> >>> There is a new method isWipeAfterDeleteSet that will be used by
> >>> commands
> >>> to set the storage type to get the default wipeAfterDeleteFlag if
> >>> wipeAfterDelete was not set.
> >>>
> >>>       public boolean isWipeAfterDeleteSet() {
> >>>           return wipeAfterDelete != null;
> >>>       }
> >>>
> >>> Now in bll.AddDiskCommand I modified executeVmCommand to add the
> >>> following
> >>>
> >>> if(!getParameters().getDiskInfo().isWipeAfterDeleteSet()) {
> >>>               StorageType storageType =
> >>> getStorageDomain().getstorage_type();
> >>> getParameters().getDiskInfo().setStorageType(storageType);
> >>>           }
> >>>
> >>> This approach minimizes the impact of changes. So all commands
> >>> interested in wipeAfterDelete flag based on storage type if
> >>> wipeAfterDelete has not been set need to set the storageType
> >>> before
> >>> calling isWipeAfterDelete.
> >>>
> >>> Please let me know if this is the solution conflicts with
> >>> something
> >>> you
> >>> have been working on. All the existing code will work as it has
> >>> been
> >>> working, if wipeAfterDelete has not been set and storageType has
> >>> not
> >>> been set the method isWipeAfterDelete return false (like it was
> >>> earlier)
> >>>
> >>
> >>
> >> Calling 'Config.<?> GetValue' in a business entity could be
> >> problematic in the UI since
> >> only the backend can invoke it (business entities are common for
> >> the
> >> backend and the UI
> >> which means that both may instantiate/manipulate them).
> >> We use GWT RPC for serializing/deserializing these business
> >> entities,
> >> thus we usually can't reference non plain java objects (or use
> >> some
> >> tweaks/tricks if applicable).
> >> Try to check the UI behavior after the new changes and let me
> >> know...
> >> [as an alternative, you can probably get 'SANWipeAfterDelete'
> >> config
> >> value from REST code (or backend)].
> >
> > clients (UI/API) can only call the ConfigurationValues enum, and
> > should use the query for it (gui has this already of course, just
> > look
> > it up)
> Yes it is going to be a problem with the UI, I will work on an
> alternative. Since this method will be called from both backend and
> frontend code, I think it is best not to have the logic to extract
> the
> default value in the BaseDisk class. I am leaning towards the
> following
> implementation, please let me know your thoughts. I also took a look
> at
> ConfigurationValues but I thinks the below works best
> 
> The only change in the BaseDisk class is changing the reference type
> for
> wipeAfterDelete flag and the addition of a new method
> 
>      public boolean isWipeAfterDeleteSet() {
>          return wipeAfterDelete != null;
>      }
> 
> and change in isWipeAfterDelete method
> 
>      public boolean isWipeAfterDelete() {
>          if (isWipeAfterDeleteSet()) {
>              return wipeAfterDelete;
>          }
>          return false;
>      }
> 
> The backend handles the logic when wipeAfterDelete flag is not set.
> So
> in AddDiskCommand executeVmCommand method we check if the flag is
> set,
> otherwise we get the storage type and get the default value using the
> new Utility class WipeAfterDeleteUtils
> 
>         if(!getParameters().getDiskInfo().isWipeAfterDeleteSet()) {
>              StorageType storageType =
>              getStorageDomain().getstorage_type();
> getParameters().getDiskInfo().setWipeAfterDelete(WipeAfterDeleteUtils.getDefaultWipeAfterDeleteFlag(storageType));
>          }
> 
> and the Utility class is a very simple class that extracts the
> default
> value based on the storagetype
> 
> public class WipeAfterDeleteUtils {
> 
>      static Boolean wipeAfterDeleteBlockStorageDomain;
> 
>      static boolean wipeAfterDeleteFileStorageDomain = false;
> 
>      public static synchronized boolean
> getDefaultWipeAfterDeleteFlag(final StorageType storageType) {
>          if(storageType.isBlockDomain()) {
>              if(wipeAfterDeleteBlockStorageDomain == null) {
>                      wipeAfterDeleteBlockStorageDomain =
> Config.<Boolean>GetValue(ConfigValues.SANWipeAfterDelete);
>              }
>              return wipeAfterDeleteBlockStorageDomain;
>          }
>          if(storageType.isFileDomain()) {
>              return wipeAfterDeleteFileStorageDomain;
>          }
>          return false;
>      }
> }
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From derez at redhat.com  Sun Oct 14 07:14:24 2012
From: derez at redhat.com (Daniel Erez)
Date: Sun, 14 Oct 2012 03:14:24 -0400 (EDT)
Subject: [Engine-devel] "wipe after delete" Matching defaults from GUI
 to	Backend
In-Reply-To: <50786EAD.8040707@redhat.com>
Message-ID: <1758673162.716415.1350198864750.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Ravi Nori" <rnori at redhat.com>
> To: "Itamar Heim" <iheim at redhat.com>
> Cc: "Daniel Erez" <derez at redhat.com>, engine-devel at ovirt.org
> Sent: Friday, October 12, 2012 9:25:33 PM
> Subject: Re: [Engine-devel] "wipe after delete" Matching defaults from GUI to	Backend
> 
> On 10/11/2012 07:50 PM, Itamar Heim wrote:
> > On 10/11/2012 05:28 PM, Daniel Erez wrote:
> >>
> >>
> >> ----- Original Message -----
> >>> From: "Ravi Nori" <rnori at redhat.com>
> >>> To: "Daniel Erez" <derez at redhat.com>
> >>> Cc: engine-devel at ovirt.org
> >>> Sent: Thursday, October 11, 2012 3:21:05 PM
> >>> Subject: Re: [Engine-devel] "wipe after delete" Matching defaults
> >>> from GUI to    Backend
> >>>
> >>> On 10/10/2012 01:17 AM, Daniel Erez wrote:
> >>>>
> >>>> ----- Original Message -----
> >>>>> From: "Ravi Nori" <rnori at redhat.com>
> >>>>> To: engine-devel at ovirt.org
> >>>>> Sent: Tuesday, October 9, 2012 6:40:56 PM
> >>>>> Subject: [Engine-devel] "wipe after delete" Matching defaults
> >>>>> from
> >>>>> GUI to    Backend
> >>>>>
> >>>>> I am working on the bug where the defaults values in the GUI
> >>>>> for
> >>>>> disk
> >>>>> actions don't correspond to the default values in the
> >>>>> API/Backend.
> >>>>> For
> >>>>> example the "wipe after delete" flag defaults to true in the
> >>>>> GUI
> >>>>> but
> >>>>> false in the backend code. Default values are not sent from the
> >>>>> frontend
> >>>>> to the backend. Please refer to the bugzilla link
> >>>>>
> >>>>> https://bugzilla.redhat.com/show_bug.cgi?id=845466
> >>>>>
> >>>>> After discussing with Michael as to how to approach fixing
> >>>>> this,
> >>>>> we
> >>>>> think the best way to do it would be to fix it in the Backend
> >>>>> class
> >>>>> businessentities.Disk by replacing primitives with reference
> >>>>> types
> >>>>> and
> >>>>> forcing business logic in the class to set the default values
> >>>>> to
> >>>>> match
> >>>>> the default values in the client.
> >>>>>
> >>>>> I would appreciate some feedback on this and also on what the
> >>>>> default
> >>>>> values are for Disk operations on the GUI.
> >>>> GUI behavior is as follows:
> >>>> For File storage domains - WipeAfterDelete check-box is
> >>>> unchangeable and unchecked (false).
> >>>> For Block storage domains - WipeAfterDelete check-box is
> >>>> changeable
> >>>> and
> >>>> the default value is according to 'SANWipeAfterDelete'
> >>>> configuration value.
> >>>>
> >>>> I think you should simply utilize the same configuration value
> >>>> in
> >>>> REST or backend when creating a new disk.
> >>>>
> >>>>> Thanks
> >>>>>
> >>>>> Ravi
> >>>>> _______________________________________________
> >>>>> Engine-devel mailing list
> >>>>> Engine-devel at ovirt.org
> >>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>>>>
> >>> Thanks for the reply.
> >>>
> >>> Here is my current implementation
> >>>
> >>> I modified businessentities.BaseDisk class to change
> >>> wipeAfterDelete
> >>> to
> >>> wrapper class (reference class) for boolean
> >>>
> >>>       private Boolean wipeAfterDelete;
> >>>
> >>> I also added default values for File and block storages
> >>>       private boolean wipeAfterDeleteFileStorageDomain = false;
> >>>       private boolean wipeAfterDeleteBlockStorageDomain =
> >>> Config.<Boolean>GetValue(ConfigValues.SANWipeAfterDelete);
> >>>
> >>> The storage type determines which of the two default values is
> >>> returned
> >>> by BaseDisk when wipeAfterDelete is not set (is null)
> >>>       StorageType storageType = StorageType.UNKNOWN;
> >>>
> >>> So isWipeAfterDeleteMethodLooks like this
> >>>
> >>>       public boolean isWipeAfterDelete() {
> >>>           if (wipeAfterDelete == null) {
> >>>               return getDefaultIsWipeAfterDelete();
> >>>           }
> >>>           return wipeAfterDelete;
> >>>       }
> >>>
> >>>       private boolean getDefaultIsWipeAfterDelete() {
> >>>           if(storageType.equals(StorageType.UNKNOWN)) {
> >>>               return false;
> >>>           }
> >>>           switch (storageType) {
> >>>               case ISCSI:
> >>>               case FCP:
> >>>                   return wipeAfterDeleteBlockStorageDomain;
> >>>               default:
> >>>                   return wipeAfterDeleteFileStorageDomain;
> >>>           }
> >>>       }
> >>>
> >>> There is a new method isWipeAfterDeleteSet that will be used by
> >>> commands
> >>> to set the storage type to get the default wipeAfterDeleteFlag if
> >>> wipeAfterDelete was not set.
> >>>
> >>>       public boolean isWipeAfterDeleteSet() {
> >>>           return wipeAfterDelete != null;
> >>>       }
> >>>
> >>> Now in bll.AddDiskCommand I modified executeVmCommand to add the
> >>> following
> >>>
> >>> if(!getParameters().getDiskInfo().isWipeAfterDeleteSet()) {
> >>>               StorageType storageType =
> >>> getStorageDomain().getstorage_type();
> >>> getParameters().getDiskInfo().setStorageType(storageType);
> >>>           }
> >>>
> >>> This approach minimizes the impact of changes. So all commands
> >>> interested in wipeAfterDelete flag based on storage type if
> >>> wipeAfterDelete has not been set need to set the storageType
> >>> before
> >>> calling isWipeAfterDelete.
> >>>
> >>> Please let me know if this is the solution conflicts with
> >>> something
> >>> you
> >>> have been working on. All the existing code will work as it has
> >>> been
> >>> working, if wipeAfterDelete has not been set and storageType has
> >>> not
> >>> been set the method isWipeAfterDelete return false (like it was
> >>> earlier)
> >>>
> >>
> >>
> >> Calling 'Config.<?> GetValue' in a business entity could be
> >> problematic in the UI since
> >> only the backend can invoke it (business entities are common for
> >> the
> >> backend and the UI
> >> which means that both may instantiate/manipulate them).
> >> We use GWT RPC for serializing/deserializing these business
> >> entities,
> >> thus we usually can't reference non plain java objects (or use
> >> some
> >> tweaks/tricks if applicable).
> >> Try to check the UI behavior after the new changes and let me
> >> know...
> >> [as an alternative, you can probably get 'SANWipeAfterDelete'
> >> config
> >> value from REST code (or backend)].
> >
> > clients (UI/API) can only call the ConfigurationValues enum, and
> > should use the query for it (gui has this already of course, just
> > look
> > it up)
> Yes it is going to be a problem with the UI, I will work on an
> alternative. Since this method will be called from both backend and
> frontend code, I think it is best not to have the logic to extract
> the
> default value in the BaseDisk class. I am leaning towards the
> following
> implementation, please let me know your thoughts. I also took a look
> at
> ConfigurationValues but I thinks the below works best
> 
> The only change in the BaseDisk class is changing the reference type
> for
> wipeAfterDelete flag and the addition of a new method
> 
>      public boolean isWipeAfterDeleteSet() {
>          return wipeAfterDelete != null;
>      }
> 
> and change in isWipeAfterDelete method
> 
>      public boolean isWipeAfterDelete() {
>          if (isWipeAfterDeleteSet()) {
>              return wipeAfterDelete;
>          }
>          return false;
>      }
> 
> The backend handles the logic when wipeAfterDelete flag is not set.
> So
> in AddDiskCommand executeVmCommand method we check if the flag is
> set,
> otherwise we get the storage type and get the default value using the
> new Utility class WipeAfterDeleteUtils
> 
>         if(!getParameters().getDiskInfo().isWipeAfterDeleteSet()) {
>              StorageType storageType =
>              getStorageDomain().getstorage_type();
> getParameters().getDiskInfo().setWipeAfterDelete(WipeAfterDeleteUtils.getDefaultWipeAfterDeleteFlag(storageType));
>          }
> 
> and the Utility class is a very simple class that extracts the
> default
> value based on the storagetype
> 
> public class WipeAfterDeleteUtils {
> 
>      static Boolean wipeAfterDeleteBlockStorageDomain;
> 
>      static boolean wipeAfterDeleteFileStorageDomain = false;
> 
>      public static synchronized boolean
> getDefaultWipeAfterDeleteFlag(final StorageType storageType) {
>          if(storageType.isBlockDomain()) {
>              if(wipeAfterDeleteBlockStorageDomain == null) {
>                      wipeAfterDeleteBlockStorageDomain =
> Config.<Boolean>GetValue(ConfigValues.SANWipeAfterDelete);
>              }
>              return wipeAfterDeleteBlockStorageDomain;
>          }
>          if(storageType.isFileDomain()) {
>              return wipeAfterDeleteFileStorageDomain;
>          }
>          return false;
>      }
> }
> 
> 

Wouldn't it be simpler to get SANWipeAfterDelete config value from REST (and keep the 'default' logic there..)?
E.g. BackendCapabilitiesResource.java -> localStorageEnabled().




From mpastern at redhat.com  Sun Oct 14 07:57:09 2012
From: mpastern at redhat.com (Michael Pasternak)
Date: Sun, 14 Oct 2012 09:57:09 +0200
Subject: [Engine-devel] "wipe after delete" Matching defaults from GUI
 to	Backend
In-Reply-To: <5076C7C1.6010405@redhat.com>
References: <1486797178.8472794.1349824625385.JavaMail.root@redhat.com>
	<5076C7C1.6010405@redhat.com>
Message-ID: <507A7055.1090306@redhat.com>

On 10/11/2012 03:21 PM, Ravi Nori wrote:
> The storage type determines which of the two default values is returned by BaseDisk when wipeAfterDelete is not set (is null)
>     StorageType storageType = StorageType.UNKNOWN;
> 
> So isWipeAfterDeleteMethodLooks like this
> 
>     public boolean isWipeAfterDelete() {
>         if (wipeAfterDelete == null) {
>             return getDefaultIsWipeAfterDelete();
>         }
>         return wipeAfterDelete;
>     }
> 
>     private boolean getDefaultIsWipeAfterDelete() {
>         if(storageType.equals(StorageType.UNKNOWN)) {
>             return false;
>         }
>         switch (storageType) {
>             case ISCSI:
>             case FCP:
>                 return wipeAfterDeleteBlockStorageDomain;
>             default:
>                 return wipeAfterDeleteFileStorageDomain;
>         }
>     }
> 

Ravi,

Is there any reason for not doing all this ^ in .ctr?
i.e iiuc wipeAfterDelete became an reference type, so you can
see if it was not set even in parameters .ctr and apply your
logic there.

(this way setter/s won't have to carry any logic)

> There is a new method isWipeAfterDeleteSet that will be used by commands to set the storage type to get the default wipeAfterDeleteFlag if wipeAfterDelete was not set.
> 
>     public boolean isWipeAfterDeleteSet() {
>         return wipeAfterDelete != null;
>     }


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From mpastern at redhat.com  Sun Oct 14 07:57:36 2012
From: mpastern at redhat.com (Michael Pasternak)
Date: Sun, 14 Oct 2012 09:57:36 +0200
Subject: [Engine-devel] "wipe after delete" Matching defaults from GUI
 to	Backend
In-Reply-To: <1758673162.716415.1350198864750.JavaMail.root@redhat.com>
References: <1758673162.716415.1350198864750.JavaMail.root@redhat.com>
Message-ID: <507A7070.5090909@redhat.com>

On 10/14/2012 09:14 AM, Daniel Erez wrote:
> 
> 
> ----- Original Message -----
>> From: "Ravi Nori" <rnori at redhat.com>
>> To: "Itamar Heim" <iheim at redhat.com>
>> Cc: "Daniel Erez" <derez at redhat.com>, engine-devel at ovirt.org
>> Sent: Friday, October 12, 2012 9:25:33 PM
>> Subject: Re: [Engine-devel] "wipe after delete" Matching defaults from GUI to	Backend
>>
>> On 10/11/2012 07:50 PM, Itamar Heim wrote:
>>> On 10/11/2012 05:28 PM, Daniel Erez wrote:
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: "Ravi Nori" <rnori at redhat.com>
>>>>> To: "Daniel Erez" <derez at redhat.com>
>>>>> Cc: engine-devel at ovirt.org
>>>>> Sent: Thursday, October 11, 2012 3:21:05 PM
>>>>> Subject: Re: [Engine-devel] "wipe after delete" Matching defaults
>>>>> from GUI to    Backend
>>>>>
>>>>> On 10/10/2012 01:17 AM, Daniel Erez wrote:
>>>>>>
>>>>>> ----- Original Message -----
>>>>>>> From: "Ravi Nori" <rnori at redhat.com>
>>>>>>> To: engine-devel at ovirt.org
>>>>>>> Sent: Tuesday, October 9, 2012 6:40:56 PM
>>>>>>> Subject: [Engine-devel] "wipe after delete" Matching defaults
>>>>>>> from
>>>>>>> GUI to    Backend
>>>>>>>
>>>>>>> I am working on the bug where the defaults values in the GUI
>>>>>>> for
>>>>>>> disk
>>>>>>> actions don't correspond to the default values in the
>>>>>>> API/Backend.
>>>>>>> For
>>>>>>> example the "wipe after delete" flag defaults to true in the
>>>>>>> GUI
>>>>>>> but
>>>>>>> false in the backend code. Default values are not sent from the
>>>>>>> frontend
>>>>>>> to the backend. Please refer to the bugzilla link
>>>>>>>
>>>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=845466
>>>>>>>
>>>>>>> After discussing with Michael as to how to approach fixing
>>>>>>> this,
>>>>>>> we
>>>>>>> think the best way to do it would be to fix it in the Backend
>>>>>>> class
>>>>>>> businessentities.Disk by replacing primitives with reference
>>>>>>> types
>>>>>>> and
>>>>>>> forcing business logic in the class to set the default values
>>>>>>> to
>>>>>>> match
>>>>>>> the default values in the client.
>>>>>>>
>>>>>>> I would appreciate some feedback on this and also on what the
>>>>>>> default
>>>>>>> values are for Disk operations on the GUI.
>>>>>> GUI behavior is as follows:
>>>>>> For File storage domains - WipeAfterDelete check-box is
>>>>>> unchangeable and unchecked (false).
>>>>>> For Block storage domains - WipeAfterDelete check-box is
>>>>>> changeable
>>>>>> and
>>>>>> the default value is according to 'SANWipeAfterDelete'
>>>>>> configuration value.
>>>>>>
>>>>>> I think you should simply utilize the same configuration value
>>>>>> in
>>>>>> REST or backend when creating a new disk.
>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>> Ravi
>>>>>>> _______________________________________________
>>>>>>> Engine-devel mailing list
>>>>>>> Engine-devel at ovirt.org
>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>>>
>>>>> Thanks for the reply.
>>>>>
>>>>> Here is my current implementation
>>>>>
>>>>> I modified businessentities.BaseDisk class to change
>>>>> wipeAfterDelete
>>>>> to
>>>>> wrapper class (reference class) for boolean
>>>>>
>>>>>       private Boolean wipeAfterDelete;
>>>>>
>>>>> I also added default values for File and block storages
>>>>>       private boolean wipeAfterDeleteFileStorageDomain = false;
>>>>>       private boolean wipeAfterDeleteBlockStorageDomain =
>>>>> Config.<Boolean>GetValue(ConfigValues.SANWipeAfterDelete);
>>>>>
>>>>> The storage type determines which of the two default values is
>>>>> returned
>>>>> by BaseDisk when wipeAfterDelete is not set (is null)
>>>>>       StorageType storageType = StorageType.UNKNOWN;
>>>>>
>>>>> So isWipeAfterDeleteMethodLooks like this
>>>>>
>>>>>       public boolean isWipeAfterDelete() {
>>>>>           if (wipeAfterDelete == null) {
>>>>>               return getDefaultIsWipeAfterDelete();
>>>>>           }
>>>>>           return wipeAfterDelete;
>>>>>       }
>>>>>
>>>>>       private boolean getDefaultIsWipeAfterDelete() {
>>>>>           if(storageType.equals(StorageType.UNKNOWN)) {
>>>>>               return false;
>>>>>           }
>>>>>           switch (storageType) {
>>>>>               case ISCSI:
>>>>>               case FCP:
>>>>>                   return wipeAfterDeleteBlockStorageDomain;
>>>>>               default:
>>>>>                   return wipeAfterDeleteFileStorageDomain;
>>>>>           }
>>>>>       }
>>>>>
>>>>> There is a new method isWipeAfterDeleteSet that will be used by
>>>>> commands
>>>>> to set the storage type to get the default wipeAfterDeleteFlag if
>>>>> wipeAfterDelete was not set.
>>>>>
>>>>>       public boolean isWipeAfterDeleteSet() {
>>>>>           return wipeAfterDelete != null;
>>>>>       }
>>>>>
>>>>> Now in bll.AddDiskCommand I modified executeVmCommand to add the
>>>>> following
>>>>>
>>>>> if(!getParameters().getDiskInfo().isWipeAfterDeleteSet()) {
>>>>>               StorageType storageType =
>>>>> getStorageDomain().getstorage_type();
>>>>> getParameters().getDiskInfo().setStorageType(storageType);
>>>>>           }
>>>>>
>>>>> This approach minimizes the impact of changes. So all commands
>>>>> interested in wipeAfterDelete flag based on storage type if
>>>>> wipeAfterDelete has not been set need to set the storageType
>>>>> before
>>>>> calling isWipeAfterDelete.
>>>>>
>>>>> Please let me know if this is the solution conflicts with
>>>>> something
>>>>> you
>>>>> have been working on. All the existing code will work as it has
>>>>> been
>>>>> working, if wipeAfterDelete has not been set and storageType has
>>>>> not
>>>>> been set the method isWipeAfterDelete return false (like it was
>>>>> earlier)
>>>>>
>>>>
>>>>
>>>> Calling 'Config.<?> GetValue' in a business entity could be
>>>> problematic in the UI since
>>>> only the backend can invoke it (business entities are common for
>>>> the
>>>> backend and the UI
>>>> which means that both may instantiate/manipulate them).
>>>> We use GWT RPC for serializing/deserializing these business
>>>> entities,
>>>> thus we usually can't reference non plain java objects (or use
>>>> some
>>>> tweaks/tricks if applicable).
>>>> Try to check the UI behavior after the new changes and let me
>>>> know...
>>>> [as an alternative, you can probably get 'SANWipeAfterDelete'
>>>> config
>>>> value from REST code (or backend)].
>>>
>>> clients (UI/API) can only call the ConfigurationValues enum, and
>>> should use the query for it (gui has this already of course, just
>>> look
>>> it up)
>> Yes it is going to be a problem with the UI, I will work on an
>> alternative. Since this method will be called from both backend and
>> frontend code, I think it is best not to have the logic to extract
>> the
>> default value in the BaseDisk class. I am leaning towards the
>> following
>> implementation, please let me know your thoughts. I also took a look
>> at
>> ConfigurationValues but I thinks the below works best
>>
>> The only change in the BaseDisk class is changing the reference type
>> for
>> wipeAfterDelete flag and the addition of a new method
>>
>>      public boolean isWipeAfterDeleteSet() {
>>          return wipeAfterDelete != null;
>>      }
>>
>> and change in isWipeAfterDelete method
>>
>>      public boolean isWipeAfterDelete() {
>>          if (isWipeAfterDeleteSet()) {
>>              return wipeAfterDelete;
>>          }
>>          return false;
>>      }
>>
>> The backend handles the logic when wipeAfterDelete flag is not set.
>> So
>> in AddDiskCommand executeVmCommand method we check if the flag is
>> set,
>> otherwise we get the storage type and get the default value using the
>> new Utility class WipeAfterDeleteUtils
>>
>>         if(!getParameters().getDiskInfo().isWipeAfterDeleteSet()) {
>>              StorageType storageType =
>>              getStorageDomain().getstorage_type();
>> getParameters().getDiskInfo().setWipeAfterDelete(WipeAfterDeleteUtils.getDefaultWipeAfterDeleteFlag(storageType));
>>          }
>>
>> and the Utility class is a very simple class that extracts the
>> default
>> value based on the storagetype
>>
>> public class WipeAfterDeleteUtils {
>>
>>      static Boolean wipeAfterDeleteBlockStorageDomain;
>>
>>      static boolean wipeAfterDeleteFileStorageDomain = false;
>>
>>      public static synchronized boolean
>> getDefaultWipeAfterDeleteFlag(final StorageType storageType) {
>>          if(storageType.isBlockDomain()) {
>>              if(wipeAfterDeleteBlockStorageDomain == null) {
>>                      wipeAfterDeleteBlockStorageDomain =
>> Config.<Boolean>GetValue(ConfigValues.SANWipeAfterDelete);
>>              }
>>              return wipeAfterDeleteBlockStorageDomain;
>>          }
>>          if(storageType.isFileDomain()) {
>>              return wipeAfterDeleteFileStorageDomain;
>>          }
>>          return false;
>>      }
>> }
>>
>>
> 
> Wouldn't it be simpler to get SANWipeAfterDelete config value from REST (and keep the 'default' logic there..)?
> E.g. BackendCapabilitiesResource.java -> localStorageEnabled().

no,

1. BackendCapabilitiesResource not used to keep any logic, but for capabilities representation
2. api is stateless
3. defaults should be assigned in object .ctr, (user can override it in parameters .ctr or via setters)
   this way both api/UI will benefit from it.

> 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From simon at redhat.com  Sun Oct 14 16:07:04 2012
From: simon at redhat.com (Simon Grinberg)
Date: Sun, 14 Oct 2012 12:07:04 -0400 (EDT)
Subject: [Engine-devel] [Users] oVirt Node 2.5.2 ISO released
In-Reply-To: <1961702153.12268949.1350227440991.JavaMail.root@redhat.com>
Message-ID: <251417381.12277665.1350230824960.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Simon Grinberg" <simon at redhat.com>
> To: "Mike Burns" <mburns at redhat.com>
> Cc: "node-devel" <node-devel at ovirt.org>
> Sent: Sunday, October 14, 2012 5:10:40 PM
> Subject: Re: [Users] oVirt Node 2.5.2 ISO released
> 
> Hi Mike,
> 
> I was trying to install it and when setting from the TUI I get an
> error message command "hostname" not found.
> Dropping into shell I get the same. /etc/sysconfig/network is getting
> the proper value, but after reboot this is not reflected in the host
> name (though the value in /etc/sysconfig/network is persisted)

OK, I managed to workaround this by directly changing the host name:
echo <new host name>  > /proc/sys/kernel/hostname

This allowed me to register the node with the engine (before that it complained on missing proper certificates)
The change does not sustain reboot, but it seems that the connection with VDSM does. 

I guess the next time point I'll be hit by this issue is live migration, but not sure about that (I don't remember if libvirt still validates the host name before migration).

> 
> Any idea?
> 
> Thanks,
> Simon.
> 
> ----- Original Message -----
> > From: "Mike Burns" <mburns at redhat.com>
> > To: "node-devel" <node-devel at ovirt.org>, "users" <users at ovirt.org>
> > Sent: Friday, October 5, 2012 6:23:11 PM
> > Subject: [Users] oVirt Node 2.5.2 ISO released
> > 
> > The long awaited and much anticipated oVirt Node 2.5.2 ISO is now
> > available on ovirt.org.  This build includes the fixed vdsm to
> > allow
> > nfs
> > based domains to be attached.
> > 
> > Thanks for the patience while we worked out the issue with NFS.
> > 
> > The oVirt Node Team
> > 
> > http://ovirt.org/releases/3.1/tools/ovirt-node-iso-2.5.2-0.1.fc17.iso
> > 
> > 
> > _______________________________________________
> > Users mailing list
> > Users at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/users
> > 
> 


From mburns at redhat.com  Mon Oct 15 01:59:25 2012
From: mburns at redhat.com (Mike Burns)
Date: Sun, 14 Oct 2012 21:59:25 -0400
Subject: [Engine-devel] [Users] oVirt Node 2.5.2 ISO released
In-Reply-To: <251417381.12277665.1350230824960.JavaMail.root@redhat.com>
References: <251417381.12277665.1350230824960.JavaMail.root@redhat.com>
Message-ID: <1350266365.6975.8.camel@beelzebub.mburnsfire.net>

On Sun, 2012-10-14 at 12:07 -0400, Simon Grinberg wrote:
> 
> ----- Original Message -----
> > From: "Simon Grinberg" <simon at redhat.com>
> > To: "Mike Burns" <mburns at redhat.com>
> > Cc: "node-devel" <node-devel at ovirt.org>
> > Sent: Sunday, October 14, 2012 5:10:40 PM
> > Subject: Re: [Users] oVirt Node 2.5.2 ISO released
> > 
> > Hi Mike,
> > 
> > I was trying to install it and when setting from the TUI I get an
> > error message command "hostname" not found.
> > Dropping into shell I get the same. /etc/sysconfig/network is getting
> > the proper value, but after reboot this is not reflected in the host
> > name (though the value in /etc/sysconfig/network is persisted)
> 
> OK, I managed to workaround this by directly changing the host name:
> echo <new host name>  > /proc/sys/kernel/hostname
> 
> This allowed me to register the node with the engine (before that it complained on missing proper certificates)
> The change does not sustain reboot, but it seems that the connection with VDSM does. 
> 
> I guess the next time point I'll be hit by this issue is live migration, but not sure about that (I don't remember if libvirt still validates the host name before migration).
> 

An iso was posted last week to address this issue, but it looks like our
auto-cleaner wiped it.  I'll be posting another build tomorrow with both
this and the sanlock selinux issue solved.

Mike


> > 
> > Any idea?
> > 
> > Thanks,
> > Simon.
> > 
> > ----- Original Message -----
> > > From: "Mike Burns" <mburns at redhat.com>
> > > To: "node-devel" <node-devel at ovirt.org>, "users" <users at ovirt.org>
> > > Sent: Friday, October 5, 2012 6:23:11 PM
> > > Subject: [Users] oVirt Node 2.5.2 ISO released
> > > 
> > > The long awaited and much anticipated oVirt Node 2.5.2 ISO is now
> > > available on ovirt.org.  This build includes the fixed vdsm to
> > > allow
> > > nfs
> > > based domains to be attached.
> > > 
> > > Thanks for the patience while we worked out the issue with NFS.
> > > 
> > > The oVirt Node Team
> > > 
> > > http://ovirt.org/releases/3.1/tools/ovirt-node-iso-2.5.2-0.1.fc17.iso
> > > 
> > > 
> > > _______________________________________________
> > > Users mailing list
> > > Users at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/users
> > > 
> > 




From mburns at redhat.com  Mon Oct 15 12:36:08 2012
From: mburns at redhat.com (Mike Burns)
Date: Mon, 15 Oct 2012 08:36:08 -0400
Subject: [Engine-devel] [node-devel] [Users] oVirt Node 2.5.2 ISO
	released
In-Reply-To: <1350266365.6975.8.camel@beelzebub.mburnsfire.net>
References: <251417381.12277665.1350230824960.JavaMail.root@redhat.com>
	<1350266365.6975.8.camel@beelzebub.mburnsfire.net>
Message-ID: <1350304568.6975.51.camel@beelzebub.mburnsfire.net>

On Sun, 2012-10-14 at 21:59 -0400, Mike Burns wrote:
> On Sun, 2012-10-14 at 12:07 -0400, Simon Grinberg wrote:
> > 
> > ----- Original Message -----
> > > From: "Simon Grinberg" <simon at redhat.com>
> > > To: "Mike Burns" <mburns at redhat.com>
> > > Cc: "node-devel" <node-devel at ovirt.org>
> > > Sent: Sunday, October 14, 2012 5:10:40 PM
> > > Subject: Re: [Users] oVirt Node 2.5.2 ISO released
> > > 
> > > Hi Mike,
> > > 
> > > I was trying to install it and when setting from the TUI I get an
> > > error message command "hostname" not found.
> > > Dropping into shell I get the same. /etc/sysconfig/network is getting
> > > the proper value, but after reboot this is not reflected in the host
> > > name (though the value in /etc/sysconfig/network is persisted)
> > 
> > OK, I managed to workaround this by directly changing the host name:
> > echo <new host name>  > /proc/sys/kernel/hostname
> > 
> > This allowed me to register the node with the engine (before that it complained on missing proper certificates)
> > The change does not sustain reboot, but it seems that the connection with VDSM does. 
> > 
> > I guess the next time point I'll be hit by this issue is live migration, but not sure about that (I don't remember if libvirt still validates the host name before migration).
> > 
> 
> An iso was posted last week to address this issue, but it looks like our
> auto-cleaner wiped it.  I'll be posting another build tomorrow with both
> this and the sanlock selinux issue solved.
> 
> Mike

A new 2.5.4 image is available now to address this and the sanlock
selinux issue.

Mike

> 
> 
> > > 
> > > Any idea?
> > > 
> > > Thanks,
> > > Simon.
> > > 
> > > ----- Original Message -----
> > > > From: "Mike Burns" <mburns at redhat.com>
> > > > To: "node-devel" <node-devel at ovirt.org>, "users" <users at ovirt.org>
> > > > Sent: Friday, October 5, 2012 6:23:11 PM
> > > > Subject: [Users] oVirt Node 2.5.2 ISO released
> > > > 
> > > > The long awaited and much anticipated oVirt Node 2.5.2 ISO is now
> > > > available on ovirt.org.  This build includes the fixed vdsm to
> > > > allow
> > > > nfs
> > > > based domains to be attached.
> > > > 
> > > > Thanks for the patience while we worked out the issue with NFS.
> > > > 
> > > > The oVirt Node Team
> > > > 
> > > > http://ovirt.org/releases/3.1/tools/ovirt-node-iso-2.5.2-0.1.fc17.iso
> > > > 
> > > > 
> > > > _______________________________________________
> > > > Users mailing list
> > > > Users at ovirt.org
> > > > http://lists.ovirt.org/mailman/listinfo/users
> > > > 
> > > 
> 
> 
> _______________________________________________
> node-devel mailing list
> node-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/node-devel




From lpeer at redhat.com  Mon Oct 15 12:45:28 2012
From: lpeer at redhat.com (Livnat Peer)
Date: Mon, 15 Oct 2012 14:45:28 +0200
Subject: [Engine-devel] RFE: Netwrok Main Tab
In-Reply-To: <606596814.5345274.1349199404659.JavaMail.root@redhat.com>
References: <606596814.5345274.1349199404659.JavaMail.root@redhat.com>
Message-ID: <507C0568.2030706@redhat.com>

On 02/10/12 19:36, Simon Grinberg wrote:
> Trying to sum up some of the suggestions ('coincidently' dropping those which I think a bit too much for first implementation :)) and add some suggestions of my own 
> 
> 1. On the hosts subtab:
>    1.1 Have a radio button that will show either 
>        1.1.1 All the hosts that this network is attached to
>        1.1.2 All the hosts where this network attached to the cluster but not to the host (Very important for non-required where the host status does not indicate something is missing)
>    1.2 Have a remove button for 1.1.1, ManageNetworks button for 1.1.2. Simple add will not do since you don't know where to add. 
> 
> 2. On the vms subtab 
>    2.1 Have a radio button that will show either 
>        2.1.1 All the vms that this network is attached to
>        2.1.2 All the vms where this network is not attached to
>    2.2 Have a 'remove' button for 2.1.1, Have 'add' button for 2.1.2
>    2.3 Allow multiple selection for both actions of 2.2
>    2.4 Add remove from all button. 
>    2.5 I would not bother to show all the nics attached to the VM from the same network, it's too rare. Just make sure there is no exception if this does exist. So the columns should have 'nic' as the first and there should be only one VM per line. If there are more then one nic per VM then just indicate 'multiple' 
> 

Can you please explain the need of 2.1.2 - "All the vms where this
network is not attached to (but attached to the cluster) "?

> 3. Templates subtab - same as VM, drop the expansion of the NICs list.
> 
> 4. Clusters subtab
>    Allow assign to multiple clusters - same as the edit in the data center tab (Just use the same dialogue)
> 
> 5. Main: You have enough space then why not add the MTU column?
> 
> 6. Queries for the sub tabs: For each needs the reverse query as well (Probably more important when adding new network)  
> 
> 
> Oops, I think I mostly added and dropped (almost) nothing :)   
> 
> Regards,
> Simon
>  
> 
> ----- Original Message -----
>> From: "Avi Tal" <atal at redhat.com>
>> To: "Yaniv Kaul" <ykaul at redhat.com>
>> Cc: engine-devel at ovirt.org
>> Sent: Monday, September 24, 2012 10:13:52 AM
>> Subject: Re: [Engine-devel] RFE: Netwrok Main Tab
>>
>>
>>
>> ----- Original Message -----
>>> From: "Yaniv Kaul" <ykaul at redhat.com>
>>> To: "Moti Asayag" <masayag at redhat.com>
>>> Cc: engine-devel at ovirt.org
>>> Sent: Sunday, September 23, 2012 6:16:47 PM
>>> Subject: Re: [Engine-devel] RFE: Netwrok Main Tab
>>>
>>> On 09/23/2012 06:12 PM, Moti Asayag wrote:
>>>> On 09/23/2012 05:01 PM, Yaniv Kaul wrote:
>>>>> On 09/23/2012 04:55 PM, Alona Kaplan wrote:
>>>>>> ----- Original Message -----
>>>>>>> From: "Avi Tal" <atal at redhat.com>
>>>>>>> To: "Alona Kaplan" <alkaplan at redhat.com>
>>>>>>> Cc: engine-devel at ovirt.org
>>>>>>> Sent: Sunday, September 23, 2012 4:17:26 PM
>>>>>>> Subject: Re: [Engine-devel] RFE: Netwrok Main Tab
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ----- Original Message -----
>>>>>>>> From: "Alona Kaplan" <alkaplan at redhat.com>
>>>>>>>> To: "Avi Tal" <atal at redhat.com>
>>>>>>>> Cc: engine-devel at ovirt.org
>>>>>>>> Sent: Sunday, September 23, 2012 1:31:32 PM
>>>>>>>> Subject: Re: [Engine-devel] RFE: Netwrok Main Tab
>>>>>>>>
>>>>>>>> 1. What actions do you suggest to add?
>>>>>>> Add, Edit and remove actions of each component.
>>>>>>>
>>>>>> Host:
>>>>>> Add- What will add action on Networks->Hosts sub tab do? Choose
>>>>>> an
>>>>>> existing host and attach the network to one of its nics?
>>>>>> How will it work? after choosing the host you will open
>>>>>> setupNetworks
>>>>>> window and just enable dragging of the selected network (in the
>>>>>> main
>>>>>> tab) to a nic? I think it is too much.
>>>>>>
>>>>>> Edit- same as add.
>>>>>>
>>>>>> Remove- What is the meaning of Remove host in network's
>>>>>> context?
>>>>>> The
>>>>>> network will be detached from the host? I think it is
>>>>>> confusing.
>>>>>>
>>>>>> Vm/Template:
>>>>>> Add: What will it do? You will choose a vm and then add a vnic
>>>>>> to
>>>>>> the
>>>>>> vm? Where will you see the vnic details?
>>>>>> Edit: Same as add.
>>>>>> Remove: You will remove all the vnics that use the selected
>>>>>> network
>>>>>> from the vm? Or do you mean to add a remove per vnic?
>>>>> For all the above: yes.
>>>>> We can certainly work on the small details, but having a main
>>>>> tab
>>>>> with
>>>>> little to no action whatsoever is kinda disappointing.
>>>> IMO adding 'assign' action in the main tab might be handy in
>>>> order
>>>> to
>>>> assign a single network in a single dialog to several clusters.
>>>>
>>>> However It is not clear to me how Add/Edit for a VM in a sub-tab
>>>> should
>>>> look like. The VM should have a list of interfaces (represented
>>>> as
>>>> sub
>>>> collection/tree).
>>>
>>> I was thinking more of right-click on the network, selecting 'Add
>>> to
>>> VM'
>>> and then selecting single/mutliple VMs from a dialog with all the
>>> VMs
>>> (yes, filtered via search).
>>> Y.
>>>
>>
>> +1
>>
>>>> What will be the meaning of 'Add' in that context? Since the VM
>>>> already
>>>> have a vNIC attached to that network. If adding another once, it
>>>> should
>>>> be enabled on the record representing the VM itself which will
>>>> confuse
>>>> the user.
>>>> Same goes for 'Edit' of a VM interface under a context of a
>>>> specific
>>>> network: in the current 'Edit VM Interface' you can change the
>>>> network.
>>>> Should the same dialog be used here as well?
>>>>
>>>> The 'Remove' option is the clearer action on this context.
>>>>
>>>>
>>>>> (example of 'small details' - yes, when clicking remove for a
>>>>> VM/template - it will remove all vNICs that use that network
>>>>> from
>>>>> the
>>>>> VM. A VM with more than one vNIC on the same network is not the
>>>>> common
>>>>> case anyway, and if you want to remove just a single vNIC, go to
>>>>> the
>>>>> VM). I think we can also live with Add/Remove only, and 'defer'
>>>>> the edit
>>>>> actions to the respectable objects (host/vm/template) edit
>>>>> dialog
>>>>> boxes
>>>>> that originates from their own main tab.
>>>>>
>>>>> Y.
>>>>>
>>>>>>>> 2. I don't understand your suggestion. You mean add
>>>>>>>> SetupNetworks
>>>>>>>> to
>>>>>>>> the Networks main tab?
>>>>>>> No.
>>>>>>> Just Thinking of a nice display which will present logical
>>>>>>> network
>>>>>>> and his connected host/vm configuration instead of passing
>>>>>>> through
>>>>>>> dub-tabs
>>>>>>> I should give it a deeper thought.
>>>>>>>
>>>>>>>
>>>>>>>> ----- Original Message -----
>>>>>>>>> From: "Avi Tal" <atal at redhat.com>
>>>>>>>>> To: "Alona Kaplan" <alkaplan at redhat.com>
>>>>>>>>> Cc: engine-devel at ovirt.org
>>>>>>>>> Sent: Thursday, September 20, 2012 6:58:05 PM
>>>>>>>>> Subject: Re: [Engine-devel] RFE: Netwrok Main Tab
>>>>>>>>>
>>>>>>>>> 1. Why not having Actions for Hosts, Vms and Templates ?
>>>>>>>>> I believe we should have those actions instead of making the
>>>>>>>>> user
>>>>>>>>> browse between 'network -> vms -> network (sub tab)' just in
>>>>>>>>> order
>>>>>>>>> to update VM's network.
>>>>>>>>>
>>>>>>>>> 2. Why having such a big window which most of the time will
>>>>>>>>> be
>>>>>>>>> empty?
>>>>>>>>>      How many logical network would be existed in the
>>>>>>>>>      system?
>>>>>>>>>      My suggestion is to go for more graphical window which
>>>>>>>>>      will
>>>>>>>>>      present:
>>>>>>>>>      A. logical networks
>>>>>>>>>      B. Multiple networks with the host configurations at
>>>>>>>>>      the
>>>>>>>>>      same
>>>>>>>>>      window: very important because most of the System
>>>>>>>>>      admins
>>>>>>>>>      would
>>>>>>>>>      like to have a bigger picture of the entire network
>>>>>>>>>      configuration
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ----- Original Message -----
>>>>>>>>> From: "Alona Kaplan" <alkaplan at redhat.com>
>>>>>>>>> To: engine-devel at ovirt.org
>>>>>>>>> Sent: Thursday, September 20, 2012 1:50:15 PM
>>>>>>>>> Subject: [Engine-devel] RFE: Netwrok Main Tab
>>>>>>>>>
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> Please review the wiki and add your comments.
>>>>>>>>>
>>>>>>>>> http://wiki.ovirt.org/wiki/Feature/NetworkMainTab
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> RFE:
>>>>>>>>> https://bugzilla.redhat.com/858742
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Alona.
>>>>>>>>> _______________________________________________
>>>>>>>>> Engine-devel mailing list
>>>>>>>>> Engine-devel at ovirt.org
>>>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>>>>>
>>>>>> _______________________________________________
>>>>>> Engine-devel mailing list
>>>>>> Engine-devel at ovirt.org
>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>> _______________________________________________
>>>>> Engine-devel mailing list
>>>>> Engine-devel at ovirt.org
>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>
>>> _______________________________________________
>>> Engine-devel mailing list
>>> Engine-devel at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 



From masayag at redhat.com  Mon Oct 15 14:33:34 2012
From: masayag at redhat.com (Moti Asayag)
Date: Mon, 15 Oct 2012 16:33:34 +0200
Subject: [Engine-devel] RFE: Netwrok Main Tab
In-Reply-To: <606596814.5345274.1349199404659.JavaMail.root@redhat.com>
References: <606596814.5345274.1349199404659.JavaMail.root@redhat.com>
Message-ID: <507C1EBE.4080303@redhat.com>

On 10/02/2012 07:36 PM, Simon Grinberg wrote:
> Trying to sum up some of the suggestions ('coincidently' dropping those which I think a bit too much for first implementation :)) and add some suggestions of my own 
> 
> 1. On the hosts subtab:
>    1.1 Have a radio button that will show either 
>        1.1.1 All the hosts that this network is attached to
>        1.1.2 All the hosts where this network attached to the cluster but not to the host (Very important for non-required where the host status does not indicate something is missing)
>    1.2 Have a remove button for 1.1.1, ManageNetworks button for 1.1.2. Simple add will not do since you don't know where to add. 
> 
> 2. On the vms subtab 
>    2.1 Have a radio button that will show either 
>        2.1.1 All the vms that this network is attached to
>        2.1.2 All the vms where this network is not attached to
>    2.2 Have a 'remove' button for 2.1.1, Have 'add' button for 2.1.2
>    2.3 Allow multiple selection for both actions of 2.2
>    2.4 Add remove from all button. 
>    2.5 I would not bother to show all the nics attached to the VM from the same network, it's too rare. Just make sure there is no exception if this does exist. So the columns should have 'nic' as the first and there should be only one VM per line. If there are more then one nic per VM then just indicate 'multiple' 
> 
> 3. Templates subtab - same as VM, drop the expansion of the NICs list.
> 
> 4. Clusters subtab
>    Allow assign to multiple clusters - same as the edit in the data center tab (Just use the same dialogue)
> 
> 5. Main: You have enough space then why not add the MTU column?

How about adding the DC version to the main tab next to the DC name? The
DC version determines which features (i.e. network features) are
supported by the DC, therefore supported for the specific network.

> 
> 6. Queries for the sub tabs: For each needs the reverse query as well (Probably more important when adding new network)  
> 
> 
> Oops, I think I mostly added and dropped (almost) nothing :)   
> 
> Regards,
> Simon
>  
> 
> ----- Original Message -----
>> From: "Avi Tal" <atal at redhat.com>
>> To: "Yaniv Kaul" <ykaul at redhat.com>
>> Cc: engine-devel at ovirt.org
>> Sent: Monday, September 24, 2012 10:13:52 AM
>> Subject: Re: [Engine-devel] RFE: Netwrok Main Tab
>>
>>
>>
>> ----- Original Message -----
>>> From: "Yaniv Kaul" <ykaul at redhat.com>
>>> To: "Moti Asayag" <masayag at redhat.com>
>>> Cc: engine-devel at ovirt.org
>>> Sent: Sunday, September 23, 2012 6:16:47 PM
>>> Subject: Re: [Engine-devel] RFE: Netwrok Main Tab
>>>
>>> On 09/23/2012 06:12 PM, Moti Asayag wrote:
>>>> On 09/23/2012 05:01 PM, Yaniv Kaul wrote:
>>>>> On 09/23/2012 04:55 PM, Alona Kaplan wrote:
>>>>>> ----- Original Message -----
>>>>>>> From: "Avi Tal" <atal at redhat.com>
>>>>>>> To: "Alona Kaplan" <alkaplan at redhat.com>
>>>>>>> Cc: engine-devel at ovirt.org
>>>>>>> Sent: Sunday, September 23, 2012 4:17:26 PM
>>>>>>> Subject: Re: [Engine-devel] RFE: Netwrok Main Tab
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ----- Original Message -----
>>>>>>>> From: "Alona Kaplan" <alkaplan at redhat.com>
>>>>>>>> To: "Avi Tal" <atal at redhat.com>
>>>>>>>> Cc: engine-devel at ovirt.org
>>>>>>>> Sent: Sunday, September 23, 2012 1:31:32 PM
>>>>>>>> Subject: Re: [Engine-devel] RFE: Netwrok Main Tab
>>>>>>>>
>>>>>>>> 1. What actions do you suggest to add?
>>>>>>> Add, Edit and remove actions of each component.
>>>>>>>
>>>>>> Host:
>>>>>> Add- What will add action on Networks->Hosts sub tab do? Choose
>>>>>> an
>>>>>> existing host and attach the network to one of its nics?
>>>>>> How will it work? after choosing the host you will open
>>>>>> setupNetworks
>>>>>> window and just enable dragging of the selected network (in the
>>>>>> main
>>>>>> tab) to a nic? I think it is too much.
>>>>>>
>>>>>> Edit- same as add.
>>>>>>
>>>>>> Remove- What is the meaning of Remove host in network's
>>>>>> context?
>>>>>> The
>>>>>> network will be detached from the host? I think it is
>>>>>> confusing.
>>>>>>
>>>>>> Vm/Template:
>>>>>> Add: What will it do? You will choose a vm and then add a vnic
>>>>>> to
>>>>>> the
>>>>>> vm? Where will you see the vnic details?
>>>>>> Edit: Same as add.
>>>>>> Remove: You will remove all the vnics that use the selected
>>>>>> network
>>>>>> from the vm? Or do you mean to add a remove per vnic?
>>>>> For all the above: yes.
>>>>> We can certainly work on the small details, but having a main
>>>>> tab
>>>>> with
>>>>> little to no action whatsoever is kinda disappointing.
>>>> IMO adding 'assign' action in the main tab might be handy in
>>>> order
>>>> to
>>>> assign a single network in a single dialog to several clusters.
>>>>
>>>> However It is not clear to me how Add/Edit for a VM in a sub-tab
>>>> should
>>>> look like. The VM should have a list of interfaces (represented
>>>> as
>>>> sub
>>>> collection/tree).
>>>
>>> I was thinking more of right-click on the network, selecting 'Add
>>> to
>>> VM'
>>> and then selecting single/mutliple VMs from a dialog with all the
>>> VMs
>>> (yes, filtered via search).
>>> Y.
>>>
>>
>> +1
>>
>>>> What will be the meaning of 'Add' in that context? Since the VM
>>>> already
>>>> have a vNIC attached to that network. If adding another once, it
>>>> should
>>>> be enabled on the record representing the VM itself which will
>>>> confuse
>>>> the user.
>>>> Same goes for 'Edit' of a VM interface under a context of a
>>>> specific
>>>> network: in the current 'Edit VM Interface' you can change the
>>>> network.
>>>> Should the same dialog be used here as well?
>>>>
>>>> The 'Remove' option is the clearer action on this context.
>>>>
>>>>
>>>>> (example of 'small details' - yes, when clicking remove for a
>>>>> VM/template - it will remove all vNICs that use that network
>>>>> from
>>>>> the
>>>>> VM. A VM with more than one vNIC on the same network is not the
>>>>> common
>>>>> case anyway, and if you want to remove just a single vNIC, go to
>>>>> the
>>>>> VM). I think we can also live with Add/Remove only, and 'defer'
>>>>> the edit
>>>>> actions to the respectable objects (host/vm/template) edit
>>>>> dialog
>>>>> boxes
>>>>> that originates from their own main tab.
>>>>>
>>>>> Y.
>>>>>
>>>>>>>> 2. I don't understand your suggestion. You mean add
>>>>>>>> SetupNetworks
>>>>>>>> to
>>>>>>>> the Networks main tab?
>>>>>>> No.
>>>>>>> Just Thinking of a nice display which will present logical
>>>>>>> network
>>>>>>> and his connected host/vm configuration instead of passing
>>>>>>> through
>>>>>>> dub-tabs
>>>>>>> I should give it a deeper thought.
>>>>>>>
>>>>>>>
>>>>>>>> ----- Original Message -----
>>>>>>>>> From: "Avi Tal" <atal at redhat.com>
>>>>>>>>> To: "Alona Kaplan" <alkaplan at redhat.com>
>>>>>>>>> Cc: engine-devel at ovirt.org
>>>>>>>>> Sent: Thursday, September 20, 2012 6:58:05 PM
>>>>>>>>> Subject: Re: [Engine-devel] RFE: Netwrok Main Tab
>>>>>>>>>
>>>>>>>>> 1. Why not having Actions for Hosts, Vms and Templates ?
>>>>>>>>> I believe we should have those actions instead of making the
>>>>>>>>> user
>>>>>>>>> browse between 'network -> vms -> network (sub tab)' just in
>>>>>>>>> order
>>>>>>>>> to update VM's network.
>>>>>>>>>
>>>>>>>>> 2. Why having such a big window which most of the time will
>>>>>>>>> be
>>>>>>>>> empty?
>>>>>>>>>      How many logical network would be existed in the
>>>>>>>>>      system?
>>>>>>>>>      My suggestion is to go for more graphical window which
>>>>>>>>>      will
>>>>>>>>>      present:
>>>>>>>>>      A. logical networks
>>>>>>>>>      B. Multiple networks with the host configurations at
>>>>>>>>>      the
>>>>>>>>>      same
>>>>>>>>>      window: very important because most of the System
>>>>>>>>>      admins
>>>>>>>>>      would
>>>>>>>>>      like to have a bigger picture of the entire network
>>>>>>>>>      configuration
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ----- Original Message -----
>>>>>>>>> From: "Alona Kaplan" <alkaplan at redhat.com>
>>>>>>>>> To: engine-devel at ovirt.org
>>>>>>>>> Sent: Thursday, September 20, 2012 1:50:15 PM
>>>>>>>>> Subject: [Engine-devel] RFE: Netwrok Main Tab
>>>>>>>>>
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> Please review the wiki and add your comments.
>>>>>>>>>
>>>>>>>>> http://wiki.ovirt.org/wiki/Feature/NetworkMainTab
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> RFE:
>>>>>>>>> https://bugzilla.redhat.com/858742
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Alona.
>>>>>>>>> _______________________________________________
>>>>>>>>> Engine-devel mailing list
>>>>>>>>> Engine-devel at ovirt.org
>>>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>>>>>
>>>>>> _______________________________________________
>>>>>> Engine-devel mailing list
>>>>>> Engine-devel at ovirt.org
>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>> _______________________________________________
>>>>> Engine-devel mailing list
>>>>> Engine-devel at ovirt.org
>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>
>>> _______________________________________________
>>> Engine-devel mailing list
>>> Engine-devel at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 



From lpeer at redhat.com  Mon Oct 15 14:47:43 2012
From: lpeer at redhat.com (Livnat Peer)
Date: Mon, 15 Oct 2012 16:47:43 +0200
Subject: [Engine-devel] RFE: Netwrok Main Tab
In-Reply-To: <507C1EBE.4080303@redhat.com>
References: <606596814.5345274.1349199404659.JavaMail.root@redhat.com>
	<507C1EBE.4080303@redhat.com>
Message-ID: <507C220F.3080208@redhat.com>

On 15/10/12 16:33, Moti Asayag wrote:
> On 10/02/2012 07:36 PM, Simon Grinberg wrote:
>> Trying to sum up some of the suggestions ('coincidently' dropping those which I think a bit too much for first implementation :)) and add some suggestions of my own 
>>
>> 1. On the hosts subtab:
>>    1.1 Have a radio button that will show either 
>>        1.1.1 All the hosts that this network is attached to
>>        1.1.2 All the hosts where this network attached to the cluster but not to the host (Very important for non-required where the host status does not indicate something is missing)
>>    1.2 Have a remove button for 1.1.1, ManageNetworks button for 1.1.2. Simple add will not do since you don't know where to add. 
>>
>> 2. On the vms subtab 
>>    2.1 Have a radio button that will show either 
>>        2.1.1 All the vms that this network is attached to
>>        2.1.2 All the vms where this network is not attached to
>>    2.2 Have a 'remove' button for 2.1.1, Have 'add' button for 2.1.2
>>    2.3 Allow multiple selection for both actions of 2.2
>>    2.4 Add remove from all button. 
>>    2.5 I would not bother to show all the nics attached to the VM from the same network, it's too rare. Just make sure there is no exception if this does exist. So the columns should have 'nic' as the first and there should be only one VM per line. If there are more then one nic per VM then just indicate 'multiple' 
>>
>> 3. Templates subtab - same as VM, drop the expansion of the NICs list.
>>
>> 4. Clusters subtab
>>    Allow assign to multiple clusters - same as the edit in the data center tab (Just use the same dialogue)
>>
>> 5. Main: You have enough space then why not add the MTU column?
> 
> How about adding the DC version to the main tab next to the DC name? The
> DC version determines which features (i.e. network features) are
> supported by the DC, therefore supported for the specific network.

Since this is a valuable information but focused on the DC and not the
network I would add that on the general subtab instead of the main tab.

> 
>>
>> 6. Queries for the sub tabs: For each needs the reverse query as well (Probably more important when adding new network)  
>>
>>
>> Oops, I think I mostly added and dropped (almost) nothing :)   
>>
>> Regards,
>> Simon
>>  
>>
>> ----- Original Message -----
>>> From: "Avi Tal" <atal at redhat.com>
>>> To: "Yaniv Kaul" <ykaul at redhat.com>
>>> Cc: engine-devel at ovirt.org
>>> Sent: Monday, September 24, 2012 10:13:52 AM
>>> Subject: Re: [Engine-devel] RFE: Netwrok Main Tab
>>>
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Yaniv Kaul" <ykaul at redhat.com>
>>>> To: "Moti Asayag" <masayag at redhat.com>
>>>> Cc: engine-devel at ovirt.org
>>>> Sent: Sunday, September 23, 2012 6:16:47 PM
>>>> Subject: Re: [Engine-devel] RFE: Netwrok Main Tab
>>>>
>>>> On 09/23/2012 06:12 PM, Moti Asayag wrote:
>>>>> On 09/23/2012 05:01 PM, Yaniv Kaul wrote:
>>>>>> On 09/23/2012 04:55 PM, Alona Kaplan wrote:
>>>>>>> ----- Original Message -----
>>>>>>>> From: "Avi Tal" <atal at redhat.com>
>>>>>>>> To: "Alona Kaplan" <alkaplan at redhat.com>
>>>>>>>> Cc: engine-devel at ovirt.org
>>>>>>>> Sent: Sunday, September 23, 2012 4:17:26 PM
>>>>>>>> Subject: Re: [Engine-devel] RFE: Netwrok Main Tab
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ----- Original Message -----
>>>>>>>>> From: "Alona Kaplan" <alkaplan at redhat.com>
>>>>>>>>> To: "Avi Tal" <atal at redhat.com>
>>>>>>>>> Cc: engine-devel at ovirt.org
>>>>>>>>> Sent: Sunday, September 23, 2012 1:31:32 PM
>>>>>>>>> Subject: Re: [Engine-devel] RFE: Netwrok Main Tab
>>>>>>>>>
>>>>>>>>> 1. What actions do you suggest to add?
>>>>>>>> Add, Edit and remove actions of each component.
>>>>>>>>
>>>>>>> Host:
>>>>>>> Add- What will add action on Networks->Hosts sub tab do? Choose
>>>>>>> an
>>>>>>> existing host and attach the network to one of its nics?
>>>>>>> How will it work? after choosing the host you will open
>>>>>>> setupNetworks
>>>>>>> window and just enable dragging of the selected network (in the
>>>>>>> main
>>>>>>> tab) to a nic? I think it is too much.
>>>>>>>
>>>>>>> Edit- same as add.
>>>>>>>
>>>>>>> Remove- What is the meaning of Remove host in network's
>>>>>>> context?
>>>>>>> The
>>>>>>> network will be detached from the host? I think it is
>>>>>>> confusing.
>>>>>>>
>>>>>>> Vm/Template:
>>>>>>> Add: What will it do? You will choose a vm and then add a vnic
>>>>>>> to
>>>>>>> the
>>>>>>> vm? Where will you see the vnic details?
>>>>>>> Edit: Same as add.
>>>>>>> Remove: You will remove all the vnics that use the selected
>>>>>>> network
>>>>>>> from the vm? Or do you mean to add a remove per vnic?
>>>>>> For all the above: yes.
>>>>>> We can certainly work on the small details, but having a main
>>>>>> tab
>>>>>> with
>>>>>> little to no action whatsoever is kinda disappointing.
>>>>> IMO adding 'assign' action in the main tab might be handy in
>>>>> order
>>>>> to
>>>>> assign a single network in a single dialog to several clusters.
>>>>>
>>>>> However It is not clear to me how Add/Edit for a VM in a sub-tab
>>>>> should
>>>>> look like. The VM should have a list of interfaces (represented
>>>>> as
>>>>> sub
>>>>> collection/tree).
>>>>
>>>> I was thinking more of right-click on the network, selecting 'Add
>>>> to
>>>> VM'
>>>> and then selecting single/mutliple VMs from a dialog with all the
>>>> VMs
>>>> (yes, filtered via search).
>>>> Y.
>>>>
>>>
>>> +1
>>>
>>>>> What will be the meaning of 'Add' in that context? Since the VM
>>>>> already
>>>>> have a vNIC attached to that network. If adding another once, it
>>>>> should
>>>>> be enabled on the record representing the VM itself which will
>>>>> confuse
>>>>> the user.
>>>>> Same goes for 'Edit' of a VM interface under a context of a
>>>>> specific
>>>>> network: in the current 'Edit VM Interface' you can change the
>>>>> network.
>>>>> Should the same dialog be used here as well?
>>>>>
>>>>> The 'Remove' option is the clearer action on this context.
>>>>>
>>>>>
>>>>>> (example of 'small details' - yes, when clicking remove for a
>>>>>> VM/template - it will remove all vNICs that use that network
>>>>>> from
>>>>>> the
>>>>>> VM. A VM with more than one vNIC on the same network is not the
>>>>>> common
>>>>>> case anyway, and if you want to remove just a single vNIC, go to
>>>>>> the
>>>>>> VM). I think we can also live with Add/Remove only, and 'defer'
>>>>>> the edit
>>>>>> actions to the respectable objects (host/vm/template) edit
>>>>>> dialog
>>>>>> boxes
>>>>>> that originates from their own main tab.
>>>>>>
>>>>>> Y.
>>>>>>
>>>>>>>>> 2. I don't understand your suggestion. You mean add
>>>>>>>>> SetupNetworks
>>>>>>>>> to
>>>>>>>>> the Networks main tab?
>>>>>>>> No.
>>>>>>>> Just Thinking of a nice display which will present logical
>>>>>>>> network
>>>>>>>> and his connected host/vm configuration instead of passing
>>>>>>>> through
>>>>>>>> dub-tabs
>>>>>>>> I should give it a deeper thought.
>>>>>>>>
>>>>>>>>
>>>>>>>>> ----- Original Message -----
>>>>>>>>>> From: "Avi Tal" <atal at redhat.com>
>>>>>>>>>> To: "Alona Kaplan" <alkaplan at redhat.com>
>>>>>>>>>> Cc: engine-devel at ovirt.org
>>>>>>>>>> Sent: Thursday, September 20, 2012 6:58:05 PM
>>>>>>>>>> Subject: Re: [Engine-devel] RFE: Netwrok Main Tab
>>>>>>>>>>
>>>>>>>>>> 1. Why not having Actions for Hosts, Vms and Templates ?
>>>>>>>>>> I believe we should have those actions instead of making the
>>>>>>>>>> user
>>>>>>>>>> browse between 'network -> vms -> network (sub tab)' just in
>>>>>>>>>> order
>>>>>>>>>> to update VM's network.
>>>>>>>>>>
>>>>>>>>>> 2. Why having such a big window which most of the time will
>>>>>>>>>> be
>>>>>>>>>> empty?
>>>>>>>>>>      How many logical network would be existed in the
>>>>>>>>>>      system?
>>>>>>>>>>      My suggestion is to go for more graphical window which
>>>>>>>>>>      will
>>>>>>>>>>      present:
>>>>>>>>>>      A. logical networks
>>>>>>>>>>      B. Multiple networks with the host configurations at
>>>>>>>>>>      the
>>>>>>>>>>      same
>>>>>>>>>>      window: very important because most of the System
>>>>>>>>>>      admins
>>>>>>>>>>      would
>>>>>>>>>>      like to have a bigger picture of the entire network
>>>>>>>>>>      configuration
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ----- Original Message -----
>>>>>>>>>> From: "Alona Kaplan" <alkaplan at redhat.com>
>>>>>>>>>> To: engine-devel at ovirt.org
>>>>>>>>>> Sent: Thursday, September 20, 2012 1:50:15 PM
>>>>>>>>>> Subject: [Engine-devel] RFE: Netwrok Main Tab
>>>>>>>>>>
>>>>>>>>>> Hi all,
>>>>>>>>>>
>>>>>>>>>> Please review the wiki and add your comments.
>>>>>>>>>>
>>>>>>>>>> http://wiki.ovirt.org/wiki/Feature/NetworkMainTab
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> RFE:
>>>>>>>>>> https://bugzilla.redhat.com/858742
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Alona.
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Engine-devel mailing list
>>>>>>>>>> Engine-devel at ovirt.org
>>>>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Engine-devel mailing list
>>>>>>> Engine-devel at ovirt.org
>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>> _______________________________________________
>>>>>> Engine-devel mailing list
>>>>>> Engine-devel at ovirt.org
>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>
>>>> _______________________________________________
>>>> Engine-devel mailing list
>>>> Engine-devel at ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>
>>> _______________________________________________
>>> Engine-devel mailing list
>>> Engine-devel at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 



From simon at redhat.com  Mon Oct 15 16:19:52 2012
From: simon at redhat.com (Simon Grinberg)
Date: Mon, 15 Oct 2012 12:19:52 -0400 (EDT)
Subject: [Engine-devel] [node-devel] [Users] oVirt Node 2.5.2
	ISO	released
In-Reply-To: <1350304568.6975.51.camel@beelzebub.mburnsfire.net>
Message-ID: <1536971254.371383.1350317992653.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Mike Burns" <mburns at redhat.com>
> To: "Simon Grinberg" <simon at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>, "node-devel" <node-devel at ovirt.org>
> Sent: Monday, October 15, 2012 2:36:08 PM
> Subject: Re: [Engine-devel] [node-devel] [Users] oVirt Node 2.5.2 ISO	released
> 
> On Sun, 2012-10-14 at 21:59 -0400, Mike Burns wrote:
> > On Sun, 2012-10-14 at 12:07 -0400, Simon Grinberg wrote:
> > > 
> > > ----- Original Message -----
> > > > From: "Simon Grinberg" <simon at redhat.com>
> > > > To: "Mike Burns" <mburns at redhat.com>
> > > > Cc: "node-devel" <node-devel at ovirt.org>
> > > > Sent: Sunday, October 14, 2012 5:10:40 PM
> > > > Subject: Re: [Users] oVirt Node 2.5.2 ISO released
> > > > 
> > > > Hi Mike,
> > > > 
> > > > I was trying to install it and when setting from the TUI I get
> > > > an
> > > > error message command "hostname" not found.
> > > > Dropping into shell I get the same. /etc/sysconfig/network is
> > > > getting
> > > > the proper value, but after reboot this is not reflected in the
> > > > host
> > > > name (though the value in /etc/sysconfig/network is persisted)
> > > 
> > > OK, I managed to workaround this by directly changing the host
> > > name:
> > > echo <new host name>  > /proc/sys/kernel/hostname
> > > 
> > > This allowed me to register the node with the engine (before that
> > > it complained on missing proper certificates)
> > > The change does not sustain reboot, but it seems that the
> > > connection with VDSM does.
> > > 
> > > I guess the next time point I'll be hit by this issue is live
> > > migration, but not sure about that (I don't remember if libvirt
> > > still validates the host name before migration).
> > > 
> > 
> > An iso was posted last week to address this issue, but it looks
> > like our
> > auto-cleaner wiped it.  I'll be posting another build tomorrow with
> > both
> > this and the sanlock selinux issue solved.
> > 
> > Mike
> 
> A new 2.5.4 image is available now to address this and the sanlock
> selinux issue.

Now the host name works fine so no need for tricks to allow it to be registered.
But NFS mount fails (even before the sanlock issue. Works well with Fedora hosts though.

The massage says:

MountError, (32, ';mount.nfs: No such device\n')

Tried to do mount from the shell and got the same while this works from the Fedora host. 

Ideas? 


In another note: Yapee I have a functional, VMs based, all in one setup on my laptop using nested virt, just would like it to work with the node as well.


> 
> Mike
> 
> > 
> > 
> > > > 
> > > > Any idea?
> > > > 
> > > > Thanks,
> > > > Simon.
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Mike Burns" <mburns at redhat.com>
> > > > > To: "node-devel" <node-devel at ovirt.org>, "users"
> > > > > <users at ovirt.org>
> > > > > Sent: Friday, October 5, 2012 6:23:11 PM
> > > > > Subject: [Users] oVirt Node 2.5.2 ISO released
> > > > > 
> > > > > The long awaited and much anticipated oVirt Node 2.5.2 ISO is
> > > > > now
> > > > > available on ovirt.org.  This build includes the fixed vdsm
> > > > > to
> > > > > allow
> > > > > nfs
> > > > > based domains to be attached.
> > > > > 
> > > > > Thanks for the patience while we worked out the issue with
> > > > > NFS.
> > > > > 
> > > > > The oVirt Node Team
> > > > > 
> > > > > http://ovirt.org/releases/3.1/tools/ovirt-node-iso-2.5.2-0.1.fc17.iso
> > > > > 
> > > > > 
> > > > > _______________________________________________
> > > > > Users mailing list
> > > > > Users at ovirt.org
> > > > > http://lists.ovirt.org/mailman/listinfo/users
> > > > > 
> > > > 
> > 
> > 
> > _______________________________________________
> > node-devel mailing list
> > node-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/node-devel
> 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From mkolesni at redhat.com  Tue Oct 16 06:20:38 2012
From: mkolesni at redhat.com (Mike Kolesnik)
Date: Tue, 16 Oct 2012 02:20:38 -0400 (EDT)
Subject: [Engine-devel] Network related hooks in vdsm
In-Reply-To: <205895767.8750976.1349880448089.JavaMail.root@redhat.com>
Message-ID: <822256894.1851239.1350368438053.JavaMail.root@redhat.com>

----- Original Message -----
> Hi everyone,
> As you know vdsm has hooks mechanism and we already support dozen of
> hooks for different needs.
> Now it's a network's time.
> We would like to get your comments regarding our proposition for
> network related hooks.
> 
> In general we are planning to prepare framework for future support of
> bunch network related hooks.
> Some of them already proposed by Itzik Brown [1] and Dan Yasny [2].
> 
> Below you can find the additional hooks list that we propose:
> 
> Note: In the first stage we can implement these hooks without any
> parameters, just to provide an entry point
>  for simple hooks.

Will the admin be able to supply a sort of free-text "custom properties" field which will be passed to the hook?

If so, at what level (in the engine entities) should it be defined?
Host NIC seems to make the most sense as this is where you actually pass this info, but perhaps it should be defined on a higher level?

> 
> Networks manipulation:
> - before_add_network(conf={}, customProperty={})
> - after_add_network(conf={}, customProperty={})
> - before_del_network(conf={}, customProperty={})
> - after_del_network(conf={}, customProperty={})
> - before_edit_network(conf={}, customProperty={})
> - after_edit_network(conf={}, customProperty={})
> - TBD
> 
> Bondings manipulations:
> - before_add_bond(conf={}, customProperty={})
> - after_add_bond(conf={}, customProperty={})
> - before_del_bond(conf={}, customProperty={})
> - after_del_bond(conf={}, customProperty={})
> - before_edit_bond(conf={}, customProperty={})
> - after_edit_bond(conf={}, customProperty={})
> - TBD
> 
> General purpose:
> - before_persist_network
> - after_persist_network
> 
> 
> Now we just need to figure out the use cases.
> 
> Your input more than welcome...
> 
> [1] http://gerrit.ovirt.org/#/c/7224/   - Adding hooks support for
> NIC hotplug
> [2] http://gerrit.ovirt.org/#/c/7547/   - Hook: Cisco VM-FEX support
> 
> 
> Regards,
>     Igor Lvovsky
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From lpeer at redhat.com  Tue Oct 16 06:40:32 2012
From: lpeer at redhat.com (Livnat Peer)
Date: Tue, 16 Oct 2012 08:40:32 +0200
Subject: [Engine-devel] Network related hooks in vdsm
In-Reply-To: <205895767.8750976.1349880448089.JavaMail.root@redhat.com>
References: <205895767.8750976.1349880448089.JavaMail.root@redhat.com>
Message-ID: <507D0160.4090305@redhat.com>

On 10/10/12 16:47, Igor Lvovsky wrote:
>   Hi everyone,
> As you know vdsm has hooks mechanism and we already support dozen of hooks for different needs.
> Now it's a network's time.
> We would like to get your comments regarding our proposition for network related hooks.
> 
> In general we are planning to prepare framework for future support of bunch network related hooks.
> Some of them already proposed by Itzik Brown [1] and Dan Yasny [2].
> 
> Below you can find the additional hooks list that we propose:
> 

Many of the API calls bellow are deprecated. Why do we want to add hooks
before/after to deprecated APIs?

> Note: In the first stage we can implement these hooks without any parameters, just to provide an entry point
>  for simple hooks.
> 
> Networks manipulation:
> - before_add_network(conf={}, customProperty={})
> - after_add_network(conf={}, customProperty={})
> - before_del_network(conf={}, customProperty={})
> - after_del_network(conf={}, customProperty={})
> - before_edit_network(conf={}, customProperty={})
> - after_edit_network(conf={}, customProperty={})
> - TBD
> 
> Bondings manipulations:
> - before_add_bond(conf={}, customProperty={})
> - after_add_bond(conf={}, customProperty={})
> - before_del_bond(conf={}, customProperty={})
> - after_del_bond(conf={}, customProperty={})
> - before_edit_bond(conf={}, customProperty={})
> - after_edit_bond(conf={}, customProperty={})
> - TBD
> 
> General purpose:
> - before_persist_network
> - after_persist_network
> 
> 
> Now we just need to figure out the use cases.
> 
> Your input more than welcome...
> 
> [1] http://gerrit.ovirt.org/#/c/7224/   - Adding hooks support for NIC hotplug
> [2] http://gerrit.ovirt.org/#/c/7547/   - Hook: Cisco VM-FEX support
> 
> 
> Regards,
>     Igor Lvovsky
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 



From mkolesni at redhat.com  Tue Oct 16 06:52:17 2012
From: mkolesni at redhat.com (Mike Kolesnik)
Date: Tue, 16 Oct 2012 02:52:17 -0400 (EDT)
Subject: [Engine-devel] Network related hooks in vdsm
In-Reply-To: <507D0160.4090305@redhat.com>
Message-ID: <52510895.1867952.1350370337778.JavaMail.root@redhat.com>

----- Original Message -----
> On 10/10/12 16:47, Igor Lvovsky wrote:
> >   Hi everyone,
> > As you know vdsm has hooks mechanism and we already support dozen
> > of hooks for different needs.
> > Now it's a network's time.
> > We would like to get your comments regarding our proposition for
> > network related hooks.
> > 
> > In general we are planning to prepare framework for future support
> > of bunch network related hooks.
> > Some of them already proposed by Itzik Brown [1] and Dan Yasny [2].
> > 
> > Below you can find the additional hooks list that we propose:
> > 
> 
> Many of the API calls bellow are deprecated. Why do we want to add
> hooks
> before/after to deprecated APIs?

They are actually still very much in use with the REST API.

Perhaps we should address just the logical entry points instead of specific commands.
A command such as setup networks can trigger multiple logical events in which hooks can be planted (same goes for edit network in a smaller scale).

> 
> > Note: In the first stage we can implement these hooks without any
> > parameters, just to provide an entry point
> >  for simple hooks.
> > 
> > Networks manipulation:
> > - before_add_network(conf={}, customProperty={})
> > - after_add_network(conf={}, customProperty={})
> > - before_del_network(conf={}, customProperty={})
> > - after_del_network(conf={}, customProperty={})
> > - before_edit_network(conf={}, customProperty={})
> > - after_edit_network(conf={}, customProperty={})
> > - TBD
> > 
> > Bondings manipulations:
> > - before_add_bond(conf={}, customProperty={})
> > - after_add_bond(conf={}, customProperty={})
> > - before_del_bond(conf={}, customProperty={})
> > - after_del_bond(conf={}, customProperty={})
> > - before_edit_bond(conf={}, customProperty={})
> > - after_edit_bond(conf={}, customProperty={})
> > - TBD
> > 
> > General purpose:
> > - before_persist_network
> > - after_persist_network
> > 
> > 
> > Now we just need to figure out the use cases.
> > 
> > Your input more than welcome...
> > 
> > [1] http://gerrit.ovirt.org/#/c/7224/   - Adding hooks support for
> > NIC hotplug
> > [2] http://gerrit.ovirt.org/#/c/7547/   - Hook: Cisco VM-FEX
> > support
> > 
> > 
> > Regards,
> >     Igor Lvovsky
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From lpeer at redhat.com  Tue Oct 16 07:31:21 2012
From: lpeer at redhat.com (Livnat Peer)
Date: Tue, 16 Oct 2012 09:31:21 +0200
Subject: [Engine-devel] Network related hooks in vdsm
In-Reply-To: <52510895.1867952.1350370337778.JavaMail.root@redhat.com>
References: <52510895.1867952.1350370337778.JavaMail.root@redhat.com>
Message-ID: <507D0D49.6060700@redhat.com>

On 16/10/12 08:52, Mike Kolesnik wrote:
> ----- Original Message -----
>> On 10/10/12 16:47, Igor Lvovsky wrote:
>>>   Hi everyone,
>>> As you know vdsm has hooks mechanism and we already support dozen
>>> of hooks for different needs.
>>> Now it's a network's time.
>>> We would like to get your comments regarding our proposition for
>>> network related hooks.
>>>
>>> In general we are planning to prepare framework for future support
>>> of bunch network related hooks.
>>> Some of them already proposed by Itzik Brown [1] and Dan Yasny [2].
>>>
>>> Below you can find the additional hooks list that we propose:
>>>
>>
>> Many of the API calls bellow are deprecated. Why do we want to add
>> hooks
>> before/after to deprecated APIs?
> 
> They are actually still very much in use with the REST API.
> 

Deprecate does not mean "not in use" but "not using it going forward".

Today if a user is using 3.1 cluster/DC in the UI or the setupNetwork
API (which is the recommended way to configure your network in 3.1 and
in future versions) the hooks for add/edit-Network won't get activated
and that is confusing to the users (and the developers).

> Perhaps we should address just the logical entry points instead of specific commands.
> A command such as setup networks can trigger multiple logical events in which hooks can be planted (same goes for edit network in a smaller scale).
> 

What you are suggesting above is to deviate from the current hook
mechanism we have in VDSM and add some logic to where/when we activate
hooks.

That's an interesting suggestion, I suggest to write a wiki page and
start thinking of the implementation implications of it.
Since I like the idea I'll work with you on the wiki and we'll see if we
can get something more useful to the users and send a formal proposal.

Livnat

>>
>>> Note: In the first stage we can implement these hooks without any
>>> parameters, just to provide an entry point
>>>  for simple hooks.
>>>
>>> Networks manipulation:
>>> - before_add_network(conf={}, customProperty={})
>>> - after_add_network(conf={}, customProperty={})
>>> - before_del_network(conf={}, customProperty={})
>>> - after_del_network(conf={}, customProperty={})
>>> - before_edit_network(conf={}, customProperty={})
>>> - after_edit_network(conf={}, customProperty={})
>>> - TBD
>>>
>>> Bondings manipulations:
>>> - before_add_bond(conf={}, customProperty={})
>>> - after_add_bond(conf={}, customProperty={})
>>> - before_del_bond(conf={}, customProperty={})
>>> - after_del_bond(conf={}, customProperty={})
>>> - before_edit_bond(conf={}, customProperty={})
>>> - after_edit_bond(conf={}, customProperty={})
>>> - TBD
>>>
>>> General purpose:
>>> - before_persist_network
>>> - after_persist_network
>>>
>>>
>>> Now we just need to figure out the use cases.
>>>
>>> Your input more than welcome...
>>>
>>> [1] http://gerrit.ovirt.org/#/c/7224/   - Adding hooks support for
>>> NIC hotplug
>>> [2] http://gerrit.ovirt.org/#/c/7547/   - Hook: Cisco VM-FEX
>>> support
>>>
>>>
>>> Regards,
>>>     Igor Lvovsky
>>> _______________________________________________
>>> Engine-devel mailing list
>>> Engine-devel at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>
>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>



From Christopher.Morrissey at netapp.com  Tue Oct 16 11:50:12 2012
From: Christopher.Morrissey at netapp.com (Morrissey, Christopher)
Date: Tue, 16 Oct 2012 11:50:12 +0000
Subject: [Engine-devel] Update on UI Plugins: context-sensitive button
 API	preview
In-Reply-To: <1031952541.7675796.1350047011301.JavaMail.root@redhat.com>
References: <562224602.7650818.1350044141235.JavaMail.root@redhat.com>
	<1031952541.7675796.1350047011301.JavaMail.root@redhat.com>
Message-ID: <D290AD8432118048947689BA3AE8A9B3E9ECEA@SACEXCMBX04-PRD.hq.netapp.com>

Hi Vojtech,

Sorry for the late reply. This API looks perfect for our needs. I look forward to getting access to it and trying it out.

-Chris

From: engine-devel-bounces at ovirt.org [mailto:engine-devel-bounces at ovirt.org] On Behalf Of Vojtech Szocs
Sent: Friday, October 12, 2012 9:04 AM
To: engine-devel
Subject: [Engine-devel] Update on UI Plugins: context-sensitive button API preview

Hi guys,

I've been working on implementing "custom context-sensitive button / menu item" plugin API feature recently, and wanted to share some code with you.

Here's a sample code that adds "Do something with selected host(s)" button to Hosts main tab data grid:

api.register({
  UiInit: function() {

    api.addMainTabActionButton('Host', 'Do something with selected host(s)', {

      onClick: function() {
        // 'arguments' contain host entities currently selected
        window.alert(arguments.length + ' host(s) selected');
        window.alert('first selected host ID = ' + arguments[0].entityId);

        // Open new popup window
        // In future, we might use "dialog UI" plugin API here
        window.open('http://example.com', '_blank');
      },

      isEnabled: function() {
        // 'true' means the button is enabled and clickable (default)
        // 'false' means the button is disabled and non-clickable

        // Enable button only when the number of selected items > 0
        return arguments.length > 0;
      },

      isAccessible: function() {
        // 'true' means the button is visible (default)
        // 'false' means the button is hidden
        return true;
      }

    });

  }
});

The signature of addMainTabActionButton plugin API function is following:

addMainTabActionButton(entityTypeName, label, actionButtonInterface)

entityTypeName indicates which main tab the button should be added to, e.g. "Host" for Host main tab. [Quick question for NetApp guys: do we want to support all main tab entity types?]

label is the title displayed on the button.

actionButtonInterface represents an object that "implements the button interface" by declaring its functions: onClick, isEnabled, isAccessible. Since JavaScript language uses different techniques and syntax to achieve OOP programming model, I've decided to keep things simple and stay with plain objects containing functions. While some JavaScript guru could advocate different approach, from WebAdmin vs. plugin integration perspective, the above mentioned approach is the easiest way. I'm also interested to hear your opinion on this.

All functions of actionButtonInterface receive currently selected item(s) as function arguments. Within a JavaScript function, "arguments" represents an implicit array of its arguments.

For now, WebAdmin will pass simple JSON-like objects to these functions, for example:

{ entityId: "<whatever>" }

In future, we can extend or modify this concept to match the contract of various oVirt REST API entities.

This feature will be part of UI Plugins PoC rev.6, which should come out next week.

Regards,
Vojtech
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20121016/856be7b7/attachment.html>

From simon at redhat.com  Tue Oct 16 12:03:58 2012
From: simon at redhat.com (Simon Grinberg)
Date: Tue, 16 Oct 2012 08:03:58 -0400 (EDT)
Subject: [Engine-devel] [node-devel] [Users] oVirt Node 2.5.2
	ISO	released
In-Reply-To: <1536971254.371383.1350317992653.JavaMail.root@redhat.com>
Message-ID: <1091240104.827980.1350389038545.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Simon Grinberg" <simon at redhat.com>
> To: "Mike Burns" <mburns at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>, "node-devel" <node-devel at ovirt.org>
> Sent: Monday, October 15, 2012 6:19:52 PM
> Subject: Re: [Engine-devel] [node-devel] [Users] oVirt Node 2.5.2 ISO	released
> 
> 
> 
> ----- Original Message -----
> > From: "Mike Burns" <mburns at redhat.com>
> > To: "Simon Grinberg" <simon at redhat.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>, "node-devel"
> > <node-devel at ovirt.org>
> > Sent: Monday, October 15, 2012 2:36:08 PM
> > Subject: Re: [Engine-devel] [node-devel] [Users] oVirt Node 2.5.2
> > ISO	released
> > 
> > On Sun, 2012-10-14 at 21:59 -0400, Mike Burns wrote:
> > > On Sun, 2012-10-14 at 12:07 -0400, Simon Grinberg wrote:
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Simon Grinberg" <simon at redhat.com>
> > > > > To: "Mike Burns" <mburns at redhat.com>
> > > > > Cc: "node-devel" <node-devel at ovirt.org>
> > > > > Sent: Sunday, October 14, 2012 5:10:40 PM
> > > > > Subject: Re: [Users] oVirt Node 2.5.2 ISO released
> > > > > 
> > > > > Hi Mike,
> > > > > 
> > > > > I was trying to install it and when setting from the TUI I
> > > > > get
> > > > > an
> > > > > error message command "hostname" not found.
> > > > > Dropping into shell I get the same. /etc/sysconfig/network is
> > > > > getting
> > > > > the proper value, but after reboot this is not reflected in
> > > > > the
> > > > > host
> > > > > name (though the value in /etc/sysconfig/network is
> > > > > persisted)
> > > > 
> > > > OK, I managed to workaround this by directly changing the host
> > > > name:
> > > > echo <new host name>  > /proc/sys/kernel/hostname
> > > > 
> > > > This allowed me to register the node with the engine (before
> > > > that
> > > > it complained on missing proper certificates)
> > > > The change does not sustain reboot, but it seems that the
> > > > connection with VDSM does.
> > > > 
> > > > I guess the next time point I'll be hit by this issue is live
> > > > migration, but not sure about that (I don't remember if libvirt
> > > > still validates the host name before migration).
> > > > 
> > > 
> > > An iso was posted last week to address this issue, but it looks
> > > like our
> > > auto-cleaner wiped it.  I'll be posting another build tomorrow
> > > with
> > > both
> > > this and the sanlock selinux issue solved.
> > > 
> > > Mike
> > 
> > A new 2.5.4 image is available now to address this and the sanlock
> > selinux issue.
> 
> Now the host name works fine so no need for tricks to allow it to be
> registered.
> But NFS mount fails (even before the sanlock issue. Works well with
> Fedora hosts though.
> 
> The massage says:
> 
> MountError, (32, ';mount.nfs: No such device\n')
> 
> Tried to do mount from the shell and got the same while this works
> from the Fedora host.
> 
> Ideas?

Same goes for ovirt-node-iso-2.5.5-0.1.fc17.
It does have same vdsm as my Fedora based host so it's not VDSM.

Error code send to GUI is cryptic as well:
2012-Oct-16, 14:00:01
	
The error code for connection engine.mylaptop.redhat.com:/home/iso returned by VDSM was following 477
	
2012-Oct-16, 14:00:01
	
The error code for connection engine.mylaptop.redhat.com:/home/data2 returned by VDSM was following 477



> 
> 
> In another note: Yapee I have a functional, VMs based, all in one
> setup on my laptop using nested virt, just would like it to work
> with the node as well.
> 
> 
> > 
> > Mike
> > 
> > > 
> > > 
> > > > > 
> > > > > Any idea?
> > > > > 
> > > > > Thanks,
> > > > > Simon.
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Mike Burns" <mburns at redhat.com>
> > > > > > To: "node-devel" <node-devel at ovirt.org>, "users"
> > > > > > <users at ovirt.org>
> > > > > > Sent: Friday, October 5, 2012 6:23:11 PM
> > > > > > Subject: [Users] oVirt Node 2.5.2 ISO released
> > > > > > 
> > > > > > The long awaited and much anticipated oVirt Node 2.5.2 ISO
> > > > > > is
> > > > > > now
> > > > > > available on ovirt.org.  This build includes the fixed vdsm
> > > > > > to
> > > > > > allow
> > > > > > nfs
> > > > > > based domains to be attached.
> > > > > > 
> > > > > > Thanks for the patience while we worked out the issue with
> > > > > > NFS.
> > > > > > 
> > > > > > The oVirt Node Team
> > > > > > 
> > > > > > http://ovirt.org/releases/3.1/tools/ovirt-node-iso-2.5.2-0.1.fc17.iso
> > > > > > 
> > > > > > 
> > > > > > _______________________________________________
> > > > > > Users mailing list
> > > > > > Users at ovirt.org
> > > > > > http://lists.ovirt.org/mailman/listinfo/users
> > > > > > 
> > > > > 
> > > 
> > > 
> > > _______________________________________________
> > > node-devel mailing list
> > > node-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/node-devel
> > 
> > 
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> 


From deadhorseconsulting at gmail.com  Wed Oct 17 02:51:30 2012
From: deadhorseconsulting at gmail.com (Dead Horse)
Date: Tue, 16 Oct 2012 21:51:30 -0500
Subject: [Engine-devel] Couple of small Feature Requests
In-Reply-To: <1350052948.3419.8.camel@dhcp-29-7.brq.redhat.com>
References: <CAEWPe=r4gsVE-32gzWygh2SUf0Xr4V6xd5FDn6hnuP=NC22srA@mail.gmail.com>
	<1350052948.3419.8.camel@dhcp-29-7.brq.redhat.com>
Message-ID: <CAEWPe=o481PZHpVSXgFy0Fx=-3ON5uzi39kYiVCeP3kT5J=evg@mail.gmail.com>

The point is valid on the random passwords in a secured environment.
However that being said the randomly generated password does make it a pain
when interacting with HTML5 based clients (SPICE or VNC) or any standalone
client for that matter.

At the very least can this to be made to be configurable? The default can
be as is but at the very least allow for configurable VNC or SPICE
passwords if so desired..

Curiously I know that the Web UI does not allow for this now but is it
possible to change the password policies via any existing engine or vdsm
configurations/parameters?
EG:
- default 120 second password re-generation, can this be altered?
- fixed vs randomly generated password?

A side note are there any plans of the horizon for integrating support or
allowing for interaction with HTML5 based clients mostly VNC but with new
SPICE HTML5 client?

- DHC

On Fri, Oct 12, 2012 at 9:42 AM, David Ja?a <djasa at redhat.com> wrote:

> Hi,
>
> Dead Horse p??e v ?t 11. 10. 2012 v 12:00 -0500:
> > Would like to make a couple of small feature requests.
> >
> > 1) Allow for the SPICE or VNC password to be set in the UI by admin's
> > or power users.
> > Benefit: (Assumes spice SSL has been disabled) allows user or admin to
> > set a password for access by a standalone remote session via vncviewer
> > or remote-viewer or the spice html5 implementation which is WIP, or
> > standalone HW thin client
> > - This may also assume that vdsm is running with SSL disabled as well
> > to have had vdsm make the neccesary changes to the qemu spice
> > configuration
>
> Drawback: users can choose repetitive and/or weak passwords. Generating
> a new random password for each connection is the best thing from
> security POV in my opinion.
>
> >
> > 2) Display currently configured OR generated password and IP/Port for
> > either VNC or SPICE console of the VM within the PUP and Admin UI
> > Benefit: At the very least a standalone remote client can be used to
> > connect once the password and IP/PORT is known for spice or VNC
> >  - Currently VNC will display a dialog that shows the this info but it
> > would be more useful to have it displayed in the UI given proper
> > privilege
>
> https://bugzilla.redhat.com/show_bug.cgi?id=843397
> https://bugzilla.redhat.com/show_bug.cgi?id=843410
>
> >
> > 3) Display the UUID of a VM in the Admin UI (similar to the how the
> > disks tab breaks down and shows DISK UUID mappings)
> > - Benefit: Easier for administrators to map UUID to VM config file
> > data in the data stores or export domains
>
> IMO full uuid should be displayed in General subtab only because it's
> too long to have it as a column.
>
> It would be nice to see it in a column though in some shortened form
> because it could probably enable relaxing of
> unique-name-of-VM-in-whole-setup restriction.
>
> David
>
> >
> > - DHC
> >
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
>
> --
>
> David Ja?a, RHCE
>
> SPICE QE based in Brno
> GPG Key:     22C33E24
> Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20121016/eaf5950f/attachment.html>

From djasa at redhat.com  Wed Oct 17 08:11:24 2012
From: djasa at redhat.com (David =?UTF-8?Q?Ja=C5=A1a?=)
Date: Wed, 17 Oct 2012 10:11:24 +0200
Subject: [Engine-devel] Couple of small Feature Requests
In-Reply-To: <CAEWPe=o481PZHpVSXgFy0Fx=-3ON5uzi39kYiVCeP3kT5J=evg@mail.gmail.com>
References: <CAEWPe=r4gsVE-32gzWygh2SUf0Xr4V6xd5FDn6hnuP=NC22srA@mail.gmail.com>
	<1350052948.3419.8.camel@dhcp-29-7.brq.redhat.com>
	<CAEWPe=o481PZHpVSXgFy0Fx=-3ON5uzi39kYiVCeP3kT5J=evg@mail.gmail.com>
Message-ID: <1350461484.31336.9.camel@dhcp-29-7.brq.redhat.com>

Dead Horse p??e v ?t 16. 10. 2012 v 21:51 -0500:
> The point is valid on the random passwords in a secured environment.
> However that being said the randomly generated password does make it a
> pain when interacting with HTML5 based clients (SPICE or VNC) or any
> standalone client for that matter.
> 

Web client: 
      * if it is integrated with UP/webadmin, the portal should give it
        password in exactly the same as it gives the password to the
        plugin
      * if it is not tied to any portal, then you should be able to
        issue XMLHttpRequest to the REST API asking for password and
        extract the temporary password from the reply (IIUC it has to
        engage rest api anyway to get host/port/sport/ca/subject info)

Standalone application can engage REST too:
http://cfergeau.blogspot.cz/2012/07/outside-boxes.html


> At the very least can this to be made to be configurable? The default
> can be as is but at the very least allow for configurable VNC or SPICE
> passwords if so desired..
> 
> Curiously I know that the Web UI does not allow for this now but is it
> possible to change the password policies via any existing engine or
> vdsm configurations/parameters?
> EG:
> - default 120 second password re-generation, can this be altered?
> - fixed vs randomly generated password?
> 

in the REST API, you can configure password validity per request (using
<expiry> tag)

> A side note are there any plans of the horizon for integrating support
> or allowing for interaction with HTML5 based clients mostly VNC but
> with new SPICE HTML5 client?

I seem to recall RFEs for that (both novnc and spice html5) but I've got
no idea if there is somebody actually working on them.

David

> 
> - DHC
> 
> On Fri, Oct 12, 2012 at 9:42 AM, David Ja?a <djasa at redhat.com> wrote:
>         Hi,
>         
>         Dead Horse p??e v ?t 11. 10. 2012 v 12:00 -0500:
>         > Would like to make a couple of small feature requests.
>         >
>         > 1) Allow for the SPICE or VNC password to be set in the UI
>         by admin's
>         > or power users.
>         > Benefit: (Assumes spice SSL has been disabled) allows user
>         or admin to
>         > set a password for access by a standalone remote session via
>         vncviewer
>         > or remote-viewer or the spice html5 implementation which is
>         WIP, or
>         > standalone HW thin client
>         > - This may also assume that vdsm is running with SSL
>         disabled as well
>         > to have had vdsm make the neccesary changes to the qemu
>         spice
>         > configuration
>         
>         
>         Drawback: users can choose repetitive and/or weak passwords.
>         Generating
>         a new random password for each connection is the best thing
>         from
>         security POV in my opinion.
>         
>         >
>         > 2) Display currently configured OR generated password and
>         IP/Port for
>         > either VNC or SPICE console of the VM within the PUP and
>         Admin UI
>         > Benefit: At the very least a standalone remote client can be
>         used to
>         > connect once the password and IP/PORT is known for spice or
>         VNC
>         >  - Currently VNC will display a dialog that shows the this
>         info but it
>         > would be more useful to have it displayed in the UI given
>         proper
>         > privilege
>         
>         
>         https://bugzilla.redhat.com/show_bug.cgi?id=843397
>         https://bugzilla.redhat.com/show_bug.cgi?id=843410
>         
>         >
>         > 3) Display the UUID of a VM in the Admin UI (similar to the
>         how the
>         > disks tab breaks down and shows DISK UUID mappings)
>         > - Benefit: Easier for administrators to map UUID to VM
>         config file
>         > data in the data stores or export domains
>         
>         
>         IMO full uuid should be displayed in General subtab only
>         because it's
>         too long to have it as a column.
>         
>         It would be nice to see it in a column though in some
>         shortened form
>         because it could probably enable relaxing of
>         unique-name-of-VM-in-whole-setup restriction.
>         
>         David
>         
>         >
>         > - DHC
>         >
>         > _______________________________________________
>         > Engine-devel mailing list
>         > Engine-devel at ovirt.org
>         > http://lists.ovirt.org/mailman/listinfo/engine-devel
>         
>         --
>         
>         David Ja?a, RHCE
>         
>         SPICE QE based in Brno
>         GPG Key:     22C33E24
>         Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24
>         
>         
>         
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel

-- 

David Ja?a, RHCE

SPICE QE based in Brno
GPG Key:     22C33E24 
Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24





From djasa at redhat.com  Wed Oct 17 16:15:57 2012
From: djasa at redhat.com (David =?UTF-8?Q?Ja=C5=A1a?=)
Date: Wed, 17 Oct 2012 18:15:57 +0200
Subject: [Engine-devel] Couple of small Feature Requests
In-Reply-To: <1350461484.31336.9.camel@dhcp-29-7.brq.redhat.com>
References: <CAEWPe=r4gsVE-32gzWygh2SUf0Xr4V6xd5FDn6hnuP=NC22srA@mail.gmail.com>
	<1350052948.3419.8.camel@dhcp-29-7.brq.redhat.com>
	<CAEWPe=o481PZHpVSXgFy0Fx=-3ON5uzi39kYiVCeP3kT5J=evg@mail.gmail.com>
	<1350461484.31336.9.camel@dhcp-29-7.brq.redhat.com>
Message-ID: <1350490557.31336.20.camel@dhcp-29-7.brq.redhat.com>

David Ja?a p??e v St 17. 10. 2012 v 10:11 +0200:
> Dead Horse p??e v ?t 16. 10. 2012 v 21:51 -0500:
> > The point is valid on the random passwords in a secured environment.
> > However that being said the randomly generated password does make it a
> > pain when interacting with HTML5 based clients (SPICE or VNC) or any
> > standalone client for that matter.
> > 
> 
> Web client: 
>       * if it is integrated with UP/webadmin, the portal should give it
>         password in exactly the same as it gives the password to the
>         plugin
>       * if it is not tied to any portal, then you should be able to
>         issue XMLHttpRequest to the REST API asking for password and
>         extract the temporary password from the reply (IIUC it has to
>         engage rest api anyway to get host/port/sport/ca/subject info)

Actually, you can't get all the necessary info via REST API as a regular
user (user with no admin role):
https://bugzilla.redhat.com/show_bug.cgi?id=867513

but that will be fixed soon hopefully.

David

> 
> Standalone application can engage REST too:
> http://cfergeau.blogspot.cz/2012/07/outside-boxes.html
> 
> 
> > At the very least can this to be made to be configurable? The default
> > can be as is but at the very least allow for configurable VNC or SPICE
> > passwords if so desired..
> > 
> > Curiously I know that the Web UI does not allow for this now but is it
> > possible to change the password policies via any existing engine or
> > vdsm configurations/parameters?
> > EG:
> > - default 120 second password re-generation, can this be altered?
> > - fixed vs randomly generated password?
> > 
> 
> in the REST API, you can configure password validity per request (using
> <expiry> tag)
> 
> > A side note are there any plans of the horizon for integrating support
> > or allowing for interaction with HTML5 based clients mostly VNC but
> > with new SPICE HTML5 client?
> 
> I seem to recall RFEs for that (both novnc and spice html5) but I've got
> no idea if there is somebody actually working on them.
> 
> David
> 
> > 
> > - DHC
> > 
> > On Fri, Oct 12, 2012 at 9:42 AM, David Ja?a <djasa at redhat.com> wrote:
> >         Hi,
> >         
> >         Dead Horse p??e v ?t 11. 10. 2012 v 12:00 -0500:
> >         > Would like to make a couple of small feature requests.
> >         >
> >         > 1) Allow for the SPICE or VNC password to be set in the UI
> >         by admin's
> >         > or power users.
> >         > Benefit: (Assumes spice SSL has been disabled) allows user
> >         or admin to
> >         > set a password for access by a standalone remote session via
> >         vncviewer
> >         > or remote-viewer or the spice html5 implementation which is
> >         WIP, or
> >         > standalone HW thin client
> >         > - This may also assume that vdsm is running with SSL
> >         disabled as well
> >         > to have had vdsm make the neccesary changes to the qemu
> >         spice
> >         > configuration
> >         
> >         
> >         Drawback: users can choose repetitive and/or weak passwords.
> >         Generating
> >         a new random password for each connection is the best thing
> >         from
> >         security POV in my opinion.
> >         
> >         >
> >         > 2) Display currently configured OR generated password and
> >         IP/Port for
> >         > either VNC or SPICE console of the VM within the PUP and
> >         Admin UI
> >         > Benefit: At the very least a standalone remote client can be
> >         used to
> >         > connect once the password and IP/PORT is known for spice or
> >         VNC
> >         >  - Currently VNC will display a dialog that shows the this
> >         info but it
> >         > would be more useful to have it displayed in the UI given
> >         proper
> >         > privilege
> >         
> >         
> >         https://bugzilla.redhat.com/show_bug.cgi?id=843397
> >         https://bugzilla.redhat.com/show_bug.cgi?id=843410
> >         
> >         >
> >         > 3) Display the UUID of a VM in the Admin UI (similar to the
> >         how the
> >         > disks tab breaks down and shows DISK UUID mappings)
> >         > - Benefit: Easier for administrators to map UUID to VM
> >         config file
> >         > data in the data stores or export domains
> >         
> >         
> >         IMO full uuid should be displayed in General subtab only
> >         because it's
> >         too long to have it as a column.
> >         
> >         It would be nice to see it in a column though in some
> >         shortened form
> >         because it could probably enable relaxing of
> >         unique-name-of-VM-in-whole-setup restriction.
> >         
> >         David
> >         
> >         >
> >         > - DHC
> >         >
> >         > _______________________________________________
> >         > Engine-devel mailing list
> >         > Engine-devel at ovirt.org
> >         > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >         
> >         --
> >         
> >         David Ja?a, RHCE
> >         
> >         SPICE QE based in Brno
> >         GPG Key:     22C33E24
> >         Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24
> >         
> >         
> >         
> > 
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> 

-- 

David Ja?a, RHCE

SPICE QE based in Brno
GPG Key:     22C33E24 
Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24





From mburns at redhat.com  Wed Oct 17 22:20:48 2012
From: mburns at redhat.com (Mike Burns)
Date: Wed, 17 Oct 2012 18:20:48 -0400
Subject: [Engine-devel] [node-devel] [Users] oVirt Node 2.5.2
	ISO	released
In-Reply-To: <1091240104.827980.1350389038545.JavaMail.root@redhat.com>
References: <1091240104.827980.1350389038545.JavaMail.root@redhat.com>
Message-ID: <1350512448.4491.55.camel@beelzebub.mburnsfire.net>

<snip>
> 
> Same goes for ovirt-node-iso-2.5.5-0.1.fc17.
> It does have same vdsm as my Fedora based host so it's not VDSM.
> 
> Error code send to GUI is cryptic as well:
> 2012-Oct-16, 14:00:01
> 	
> The error code for connection engine.mylaptop.redhat.com:/home/iso returned by VDSM was following 477
> 	
> 2012-Oct-16, 14:00:01
> 	
> The error code for connection engine.mylaptop.redhat.com:/home/data2 returned by VDSM was following 477

Can you try the 2.5.5-0.1.fc17 build here[1].

The previous build didn't pick up the changes correctly, so I respun it.

Thanks

Mike

[1] http://ovirt.org/releases/nightly/iso/ovirt-node-iso-2.5.5-0.1.fc17.iso

> 
> 
<snip>



From iheim at redhat.com  Thu Oct 18 00:04:27 2012
From: iheim at redhat.com (Itamar Heim)
Date: Thu, 18 Oct 2012 02:04:27 +0200
Subject: [Engine-devel] Couple of small Feature Requests
In-Reply-To: <CAEWPe=o481PZHpVSXgFy0Fx=-3ON5uzi39kYiVCeP3kT5J=evg@mail.gmail.com>
References: <CAEWPe=r4gsVE-32gzWygh2SUf0Xr4V6xd5FDn6hnuP=NC22srA@mail.gmail.com>
	<1350052948.3419.8.camel@dhcp-29-7.brq.redhat.com>
	<CAEWPe=o481PZHpVSXgFy0Fx=-3ON5uzi39kYiVCeP3kT5J=evg@mail.gmail.com>
Message-ID: <507F478B.8030909@redhat.com>

On 10/17/2012 04:51 AM, Dead Horse wrote:
> The point is valid on the random passwords in a secured environment.
> However that being said the randomly generated password does make it a
> pain when interacting with HTML5 based clients (SPICE or VNC) or any
> standalone client for that matter.
>
> At the very least can this to be made to be configurable? The default
> can be as is but at the very least allow for configurable VNC or SPICE
> passwords if so desired..
>
> Curiously I know that the Web UI does not allow for this now but is it
> possible to change the password policies via any existing engine or vdsm
> configurations/parameters?
> EG:
> - default 120 second password re-generation, can this be altered?
> - fixed vs randomly generated password?
>
> A side note are there any plans of the horizon for integrating support
> or allowing for interaction with HTML5 based clients mostly VNC but with
> new SPICE HTML5 client?

it is configurable, just need to fix the dialog to accept the TTL of the 
password, or allow to accept the password from the user.
you can do both via the REST API.

you can either pass a password to the engine, or not pass a password, 
and then engine will generate a random one for you.

HTH,
    Itamar


From iheim at redhat.com  Thu Oct 18 00:05:08 2012
From: iheim at redhat.com (Itamar Heim)
Date: Thu, 18 Oct 2012 02:05:08 +0200
Subject: [Engine-devel] Couple of small Feature Requests
In-Reply-To: <CAEWPe=r4gsVE-32gzWygh2SUf0Xr4V6xd5FDn6hnuP=NC22srA@mail.gmail.com>
References: <CAEWPe=r4gsVE-32gzWygh2SUf0Xr4V6xd5FDn6hnuP=NC22srA@mail.gmail.com>
Message-ID: <507F47B4.1070101@redhat.com>

On 10/11/2012 07:00 PM, Dead Horse wrote:
> Would like to make a couple of small feature requests.
>
> 1) Allow for the SPICE or VNC password to be set in the UI by admin's or
> power users.
> Benefit: (Assumes spice SSL has been disabled) allows user or admin to
> set a password for access by a standalone remote session via vncviewer
> or remote-viewer or the spice html5 implementation which is WIP, or
> standalone HW thin client
> - This may also assume that vdsm is running with SSL disabled as well to
> have had vdsm make the neccesary changes to the qemu spice configuration
>
> 2) Display currently configured OR generated password and IP/Port for
> either VNC or SPICE console of the VM within the PUP and Admin UI
> Benefit: At the very least a standalone remote client can be used to
> connect once the password and IP/PORT is known for spice or VNC
>   - Currently VNC will display a dialog that shows the this info but it
> would be more useful to have it displayed in the UI given proper privilege
>
> 3) Display the UUID of a VM in the Admin UI (similar to the how the
> disks tab breaks down and shows DISK UUID mappings)
> - Benefit: Easier for administrators to map UUID to VM config file data
> in the data stores or export domains

please open bugzilla's for these to keep track of them.
thanks


From iheim at redhat.com  Thu Oct 18 00:18:54 2012
From: iheim at redhat.com (Itamar Heim)
Date: Thu, 18 Oct 2012 02:18:54 +0200
Subject: [Engine-devel] [vdsm]  Network related hooks in vdsm
In-Reply-To: <507D0D49.6060700@redhat.com>
References: <52510895.1867952.1350370337778.JavaMail.root@redhat.com>
	<507D0D49.6060700@redhat.com>
Message-ID: <507F4AEE.9060506@redhat.com>

On 10/16/2012 09:31 AM, Livnat Peer wrote:
> On 16/10/12 08:52, Mike Kolesnik wrote:
>> ----- Original Message -----
>>> On 10/10/12 16:47, Igor Lvovsky wrote:
>>>>    Hi everyone,
>>>> As you know vdsm has hooks mechanism and we already support dozen
>>>> of hooks for different needs.
>>>> Now it's a network's time.
>>>> We would like to get your comments regarding our proposition for
>>>> network related hooks.
>>>>
>>>> In general we are planning to prepare framework for future support
>>>> of bunch network related hooks.
>>>> Some of them already proposed by Itzik Brown [1] and Dan Yasny [2].
>>>>
>>>> Below you can find the additional hooks list that we propose:
>>>>
>>>
>>> Many of the API calls bellow are deprecated. Why do we want to add
>>> hooks
>>> before/after to deprecated APIs?
>>
>> They are actually still very much in use with the REST API.
>>
>
> Deprecate does not mean "not in use" but "not using it going forward".
>
> Today if a user is using 3.1 cluster/DC in the UI or the setupNetwork
> API (which is the recommended way to configure your network in 3.1 and
> in future versions) the hooks for add/edit-Network won't get activated
> and that is confusing to the users (and the developers).
>
>> Perhaps we should address just the logical entry points instead of specific commands.
>> A command such as setup networks can trigger multiple logical events in which hooks can be planted (same goes for edit network in a smaller scale).
>>
>
> What you are suggesting above is to deviate from the current hook
> mechanism we have in VDSM and add some logic to where/when we activate
> hooks.
>
> That's an interesting suggestion, I suggest to write a wiki page and
> start thinking of the implementation implications of it.
> Since I like the idea I'll work with you on the wiki and we'll see if we
> can get something more useful to the users and send a formal proposal.


question is there is any high demand/priority for network hooks other 
than hotplug nic, and do we have a clear vision of a stable api for them.

one thing to consider is allowing to define custom properties at logical 
network and virtual nic level though.


From iheim at redhat.com  Thu Oct 18 12:50:43 2012
From: iheim at redhat.com (Itamar Heim)
Date: Thu, 18 Oct 2012 14:50:43 +0200
Subject: [Engine-devel] Question about hasMemoryToRunVM() in
	RunVmCommandBase
In-Reply-To: <CANDY9WNP77dtoMqUa9qokRUDsM+K5=WYzuYav_yCgbWXEhXF2Q@mail.gmail.com>
References: <CANDY9WNP77dtoMqUa9qokRUDsM+K5=WYzuYav_yCgbWXEhXF2Q@mail.gmail.com>
Message-ID: <507FFB23.5020907@redhat.com>

On 10/18/2012 02:43 PM, ly pan wrote:
> Hi:
>
> This is my test environment:
> hardware: Dell PowerEdge 2710 ,Memory 48G
> Software: OVirt engine 3.0 ,VDSM 4.9.4 ,kernel 2.6.32-279.2.1.el6.x86_64
>
>
> I create 100 vms from pool(each vm has 512M memory and has
> 1M memory garanteed, with guest_overhead = 65 and reserved_mem = 256),
> but only 83 vms
> turn out to run. When I run the 84th vm, engine says there is not
> enough memory. However at this time KSM is enabled and 15G free memory
> is still left on the host.
>
> I checked the code and found out that before running a vm, the
> function hasMemoryToRunVM() in RunVmCommandBase would decide whether
> there is enough memory in the selected host to run it.
> The Algorithm in the function is like this:
> mem_avaliable >= mem_required = curVds.getmem_commited() +
> curVds.getpending_vmem_size()
>       + curVds.getguest_overhead() + curVds.getreserved_mem() +
> vm.getMinAllocatedMem();
>
> And here is my question: curVds.getmem_commited() is caculated from
> the memory of vm

iirc, getmem_committed is the amount of memory actually used on the 
host, as vdsm reports.

> assigned by user. But when the host is running with KSM enabled, the
> actual memory of each
> running vm would be smaller than the memory the user assigned to. In
> this case, the following
> may occur: engine says there be no more memroy to run any vm while the
> host has much free
> space to run more vms(in my case, 15G).
>
>
> Therefore I think the actual memory size reported by vdsm(The KSM
> shared memory) should be taken into account when calculating
> curVds.getmem_commited(). Any ideas are welcome.
>




From rgolan at redhat.com  Thu Oct 18 13:17:24 2012
From: rgolan at redhat.com (Roy Golan)
Date: Thu, 18 Oct 2012 15:17:24 +0200
Subject: [Engine-devel] Question about hasMemoryToRunVM() in
	RunVmCommandBase
In-Reply-To: <507FFB23.5020907@redhat.com>
References: <CANDY9WNP77dtoMqUa9qokRUDsM+K5=WYzuYav_yCgbWXEhXF2Q@mail.gmail.com>
	<507FFB23.5020907@redhat.com>
Message-ID: <50800164.8070006@redhat.com>

On 10/18/2012 02:50 PM, Itamar Heim wrote:
> On 10/18/2012 02:43 PM, ly pan wrote:
>> Hi:
>>
>> This is my test environment:
>> hardware: Dell PowerEdge 2710 ,Memory 48G
>> Software: OVirt engine 3.0 ,VDSM 4.9.4 ,kernel 2.6.32-279.2.1.el6.x86_64
>>
>>
>> I create 100 vms from pool(each vm has 512M memory and has
>> 1M memory garanteed, with guest_overhead = 65 and reserved_mem = 256),
>> but only 83 vms
>> turn out to run. When I run the 84th vm, engine says there is not
>> enough memory. However at this time KSM is enabled and 15G free memory
>> is still left on the host.
>>
>> I checked the code and found out that before running a vm, the
>> function hasMemoryToRunVM() in RunVmCommandBase would decide whether
>> there is enough memory in the selected host to run it.
>> The Algorithm in the function is like this:
>> mem_avaliable >= mem_required = curVds.getmem_commited() +
>> curVds.getpending_vmem_size()
>>       + curVds.getguest_overhead() + curVds.getreserved_mem() +
>> vm.getMinAllocatedMem();
>>
>> And here is my question: curVds.getmem_commited() is caculated from
>> the memory of vm
>
> iirc, getmem_committed is the amount of memory actually used on the 
> host, as vdsm reports.
its actually the sum of static memory per running VM on the host(as 
mentioned below)
>
>> assigned by user. But when the host is running with KSM enabled, the
>> actual memory of each
>> running vm would be smaller than the memory the user assigned to. In
>> this case, the following
>> may occur: engine says there be no more memroy to run any vm while the
>> host has much free
>> space to run more vms(in my case, 15G).
>>
>>
>> Therefore I think the actual memory size reported by vdsm(The KSM
>> shared memory) should be taken into account when calculating
>> curVds.getmem_commited(). Any ideas are welcome.
>>

in short we rather depend on static resource allocation - for scheduling 
new VMs we have to guarantee the amount of memory defined for them is 
reserved.
Free Memory by KSM is subjected to reallocation - say you updated one of 
the VMs OS, the pages are no longer equal and more memory is allocated 
for them.
>
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel



From plysab at gmail.com  Thu Oct 18 12:43:35 2012
From: plysab at gmail.com (ly pan)
Date: Thu, 18 Oct 2012 20:43:35 +0800
Subject: [Engine-devel] Question about hasMemoryToRunVM() in RunVmCommandBase
Message-ID: <CANDY9WNP77dtoMqUa9qokRUDsM+K5=WYzuYav_yCgbWXEhXF2Q@mail.gmail.com>

Hi:

This is my test environment:
hardware: Dell PowerEdge 2710 ,Memory 48G
Software: OVirt engine 3.0 ,VDSM 4.9.4 ,kernel 2.6.32-279.2.1.el6.x86_64


I create 100 vms from pool(each vm has 512M memory and has
1M memory garanteed, with guest_overhead = 65 and reserved_mem = 256),
but only 83 vms
turn out to run. When I run the 84th vm, engine says there is not
enough memory. However at this time KSM is enabled and 15G free memory
is still left on the host.

I checked the code and found out that before running a vm, the
function hasMemoryToRunVM() in RunVmCommandBase would decide whether
there is enough memory in the selected host to run it.
The Algorithm in the function is like this:
mem_avaliable >= mem_required = curVds.getmem_commited() +
curVds.getpending_vmem_size()
     + curVds.getguest_overhead() + curVds.getreserved_mem() +
vm.getMinAllocatedMem();

And here is my question: curVds.getmem_commited() is caculated from
the memory of vm
assigned by user. But when the host is running with KSM enabled, the
actual memory of each
running vm would be smaller than the memory the user assigned to. In
this case, the following
may occur: engine says there be no more memroy to run any vm while the
host has much free
space to run more vms(in my case, 15G).


Therefore I think the actual memory size reported by vdsm(The KSM
shared memory) should be taken into account when calculating
curVds.getmem_commited(). Any ideas are welcome.


From vszocs at redhat.com  Thu Oct 18 14:49:29 2012
From: vszocs at redhat.com (Vojtech Szocs)
Date: Thu, 18 Oct 2012 10:49:29 -0400 (EDT)
Subject: [Engine-devel] UI Plugins: PoC patch revision 6 now available
In-Reply-To: <115181010.9625315.1350553113828.JavaMail.root@redhat.com>
Message-ID: <803798668.9716072.1350571769692.JavaMail.root@redhat.com>

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 <OVIRT_HOME>/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, but this isn't relevant in our case). 

In contrast with traditional class-based object-oriented languages, JavaScript supports OOP through prototype-based programming model (https://developer.mozilla.org/en-US/docs/JavaScript/Introduction_to_Object-Oriented_JavaScript). At the same time, JavaScript language is dynamically-typed and therefore doesn't support traditional concept of interface in OOP, it uses "duck typing" technique instead (http://en.wikipedia.org/wiki/Duck_typing). 

The simplest way to provide an object that "implements the given interface" in JavaScript is to use "duck typing" technique: providing an object that contains well-known functions. In UI plugin infrastructure, I call this concept "interface object", represented by org.ovirt.engine.ui.webadmin.plugin.jsni.JsInterfaceObject class. Unlike the traditional concept of interface abstract type in object-oriented languages, an "interface object" does not necessarily have to declare all functions of the given interface in order to "implement" such interface. In fact, an empty object can be used as a valid "interface object". Missing functions will be simply treated as empty (no-op) functions. Furthermore, an "interface object" can "implement" multiple interfaces by declaring functions of those interfaces (interface composition). 

Getting back to "addMainTabActionButton" API, here's a sample code that adds new button to "Host" main tab data grid, as part of UiInit event handler function: 

UiInit: function () { 
api. addMainTabActionButton ('Host', 'Single-Host Action', 

// Action button interface object 
// All functions receive currently selected item(s) as function arguments 
{ 

// Called when the user clicks the button 
onClick : function () { 
// Calling 'arguments[0]' is safe, because onClick() can be called 
// only when exactly one item is currently selected in the data grid 
window.alert('Selected host entity ID = ' + arguments[0].entityId); 
}, 

// Returning 'true' means the button is enabled (clickable) 
// Returning 'false' means the button is disabled (non-clickable) 
// Default value = 'true' 
isEnabled : function () { 
// Enable button only when exactly one item is selected 
return arguments.length == 1; 
}, 

// Returning 'true' means the button is visible 
// Returning 'false' means the button is hidden 
// Default value = 'true' 
isAccessible : function () { 
// Always show the button in the corresponding data grid 
return true ; 
} 

} 

); 
} 

As mentioned above, all functions of an interface object are optional. For functions expecting return value, default value is defined by UI plugin infrastructure. For example: 

    * onClick - no default value (no return value expected) 
    * isEnabled / isAccessible - default value "true" (boolean return value expected) 


Note: UI plugin infrastructure checks the actual return value type, and uses default value in case the function returned something of wrong (unexpected) type. 

In the example above, "currently selected item(s)" maps to JSON-like representations of business entities currently selected in the corresponding data grid. For now, the entity representation is quite simple and same for all entity types: 

{ entityId: "[BusinessEntityGuidAsString]" } 

In future, we will create specific JSON-like representations for specific business entities, in compliance with Engine REST API entity structure. 

For a more extensive example of using "addMainTabActionButton" API, please see the attached "addMainTabActionButton.html.example" file. 



2. Improved plugin API function: addMainTab 

The "addMainTab" API was improved to address following issues: 

    * "addMainTab" can now be called at any moment during UI plugin runtime, given that the plugin is allowed invoke plugin API functions (plugin is either INITIALIZING or IN_USE). Previously, "addMainTab" worked reliably only when called from within UiInit event handler function. Currently, it's possible to call "addMainTab" at any moment, e.g. from within some other event handler function (after UiInit has completed). 


    * 
"addMainTab" now retains "active" tab (highlighted tab GUI). "addMainTab" works by adding new tab component (GWTP presenter proxy) and refreshing main tab panel GUI by removing all related tabs and re-adding them again. This logic is handled by org.ovirt.engine.ui.common.presenter.DynamicTabContainerPresenter class, which makes sure that "active" tab is retained even after main tab panel was refreshed. 

Furthermore, custom main tab implementation now displays the content of the given URL through HTML iframe element. 



3. Improved native JavaScript function handling (GWT JSNI) 

This patch introduces org.ovirt.engine.ui.webadmin.plugin.jsni.JsFunction and org.ovirt.engine.ui.webadmin.plugin.jsni.JsFunctionResultHelper classes providing Java abstraction for invoking native JavaScript functions. These classes follow the general contract of "interface object" as mentioned above. 

JsFunctionResultHelper is particularly useful when dealing with functions which are expected to return value of a certain type. Too bad standard GWT JSNI classes don't provide such abstraction for working with native functions out-of-the-box... 



4 . ActionPanel and ActionTable type hierarchy refactoring (related to "addMainTabActionButton" API) 

Previously, AbstractActionPanel and AbstractActionTable classes didn't implement any reasonable interface that would allow other components (client-side UI plugin infrastructure) to depend on their functionality in a loosely-coupled manner. This would make code that implements "addMainTabActionButton" API "ugly": main tab view interface would have to reference AbstractActionTable class directly. In MVP design pattern, view interface should avoid referencing specific GWT Widget classes directly. 

This patch introduces new interfaces for ActionPanel and ActionTable components while eliminating code redundancy (duplicate or unnecessary code). 



5. ActionPanel type hierarchy refactoring (related to "addMainTab" API) 

Since org.ovirt.engine.ui.common.presenter.DynamicTabContainerPresenter defines new DynamicTabPanel interface that extends standard GWTP TabPanel interface, some refactoring had to be done in related ActionPanel classes. 

This patch makes sure that both org.ovirt.engine.ui.common.widget.tab.AbstractTabPanel (widget) and org.ovirt.engine.ui.common.view.AbstractTabPanelView (view) support DynamicTabPanel interface. 

Note that for now, only main tab panel (org.ovirt.engine.ui.webadmin.section.main.presenter.MainTabPanelPresenter) supports dynamic tabs within its view. 



Where is addSubTab API function? 

Implementing "addSubTab" API requires some more changes, and I didn't want to delay this PoC patch just because of it... 

Here's a sample code that illustrates proposed "addSubTab" API usage: 

UiInit: function () { 
api. addSubTab ('Host', // entityTypeName 
'Custom Host Sub Tab', // label 
'custom-host-sub-tab', // historyToken 
'http://www.ovirt.org/', // contentUrl 

// Sub tab interface object 
// All functions receive currently selected item(s) 
// within the main tab data grid as function arguments 
{ 

// Returning 'true' means the sub tab is visible 
// Returning 'false' means the sub tab is hidden 
// Default value = 'true' 
isAccessible : function () { 
return arguments.length == 1 && arguments[0].entityId == '<MyHostEntityId>' ; 
} 

} 

); 
} 

As part of "addSubTab" API implementation, I'll refactor custom main tab components, in order to use one "tab type" for both main and sub tabs. 

Currently, we have one (and only one) "tab type" - a tab that shows content of the given URL through HTML iframe element. 

We could also create new "tab types", e.g. form-based tab that shows key/value pairs (IMHO this could be quite useful for custom sub tabs). 



Let me know what you think! 

Cheers, 
Vojtech 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20121018/ae10519c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: poc-6-examples.tar.gz
Type: application/x-compressed-tar
Size: 735 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20121018/ae10519c/attachment.bin>

From simon at redhat.com  Thu Oct 18 16:04:45 2012
From: simon at redhat.com (Simon Grinberg)
Date: Thu, 18 Oct 2012 12:04:45 -0400 (EDT)
Subject: [Engine-devel] [node-devel] [Users] oVirt Node
	2.5.2	ISO	released
In-Reply-To: <1350512448.4491.55.camel@beelzebub.mburnsfire.net>
Message-ID: <382599750.2405409.1350576285173.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Mike Burns" <mburns at redhat.com>
> To: "Simon Grinberg" <simon at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>, "node-devel" <node-devel at ovirt.org>
> Sent: Thursday, October 18, 2012 12:20:48 AM
> Subject: Re: [Engine-devel] [node-devel] [Users] oVirt Node 2.5.2	ISO	released
> 
> <snip>
> > 
> > Same goes for ovirt-node-iso-2.5.5-0.1.fc17.
> > It does have same vdsm as my Fedora based host so it's not VDSM.
> > 
> > Error code send to GUI is cryptic as well:
> > 2012-Oct-16, 14:00:01
> > 	
> > The error code for connection engine.mylaptop.redhat.com:/home/iso
> > returned by VDSM was following 477
> > 	
> > 2012-Oct-16, 14:00:01
> > 	
> > The error code for connection
> > engine.mylaptop.redhat.com:/home/data2 returned by VDSM was
> > following 477
> 
> Can you try the 2.5.5-0.1.fc17 build here[1].
> 
> The previous build didn't pick up the changes correctly, so I respun
> it.
> 
> Thanks

Finally, I have a node running :)

> 
> Mike
> 
> [1]
> http://ovirt.org/releases/nightly/iso/ovirt-node-iso-2.5.5-0.1.fc17.iso
> 
> > 
> > 
> <snip>
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From djasa at redhat.com  Fri Oct 19 10:01:52 2012
From: djasa at redhat.com (David =?UTF-8?Q?Ja=C5=A1a?=)
Date: Fri, 19 Oct 2012 12:01:52 +0200
Subject: [Engine-devel] Couple of small Feature Requests
In-Reply-To: <1350461484.31336.9.camel@dhcp-29-7.brq.redhat.com>
References: <CAEWPe=r4gsVE-32gzWygh2SUf0Xr4V6xd5FDn6hnuP=NC22srA@mail.gmail.com>
	<1350052948.3419.8.camel@dhcp-29-7.brq.redhat.com>
	<CAEWPe=o481PZHpVSXgFy0Fx=-3ON5uzi39kYiVCeP3kT5J=evg@mail.gmail.com>
	<1350461484.31336.9.camel@dhcp-29-7.brq.redhat.com>
Message-ID: <1350640912.3173.608.camel@dhcp-29-7.brq.redhat.com>

David Ja?a p??e v St 17. 10. 2012 v 10:11 +0200:
> Dead Horse p??e v ?t 16. 10. 2012 v 21:51 -0500:
> > The point is valid on the random passwords in a secured environment.
> > However that being said the randomly generated password does make it a
> > pain when interacting with HTML5 based clients (SPICE or VNC) or any
> > standalone client for that matter.
> > 

You can set custom password using REST API too but REST means you'd need
XHR anyway so using generated passwords is more secure with lesser or
equal pain:

$ curl --cacert .certs/my_rhevm.pem -D - -u djasa at my-domain.example.com:my_ovirt_password -H "Content-Type: application/xml" -H "filter: true" -X POST -d "<action><ticket><value>secret</value></ticket></action>" https://my-engine.example.com/api/vms/ad5f7497-120d-40da-9093-c9c4b8919e50/ticket
HTTP/1.1 200 OK
Date: Fri, 19 Oct 2012 09:51:26 GMT
Set-Cookie: JSESSIONID=ceH5zj17Gu+BKRztkYSDffHY; Path=/api; Secure
Content-Type: application/xml
Content-Length: 221
Connection: close

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<action>
    <ticket>
        <value>secret</value>
        <expiry>7200</expiry>
    </ticket>
    <status>
        <state>complete</state>
    </status>
</action>


David

> 
> Web client: 
>       * if it is integrated with UP/webadmin, the portal should give it
>         password in exactly the same as it gives the password to the
>         plugin
>       * if it is not tied to any portal, then you should be able to
>         issue XMLHttpRequest to the REST API asking for password and
>         extract the temporary password from the reply (IIUC it has to
>         engage rest api anyway to get host/port/sport/ca/subject info)
> 
> Standalone application can engage REST too:
> http://cfergeau.blogspot.cz/2012/07/outside-boxes.html
> 
> 
> > At the very least can this to be made to be configurable? The default
> > can be as is but at the very least allow for configurable VNC or SPICE
> > passwords if so desired..
> > 
> > Curiously I know that the Web UI does not allow for this now but is it
> > possible to change the password policies via any existing engine or
> > vdsm configurations/parameters?
> > EG:
> > - default 120 second password re-generation, can this be altered?
> > - fixed vs randomly generated password?
> > 
> 
> in the REST API, you can configure password validity per request (using
> <expiry> tag)
> 
> > A side note are there any plans of the horizon for integrating support
> > or allowing for interaction with HTML5 based clients mostly VNC but
> > with new SPICE HTML5 client?
> 
> I seem to recall RFEs for that (both novnc and spice html5) but I've got
> no idea if there is somebody actually working on them.
> 
> David
> 
> > 
> > - DHC
> > 
> > On Fri, Oct 12, 2012 at 9:42 AM, David Ja?a <djasa at redhat.com> wrote:
> >         Hi,
> >         
> >         Dead Horse p??e v ?t 11. 10. 2012 v 12:00 -0500:
> >         > Would like to make a couple of small feature requests.
> >         >
> >         > 1) Allow for the SPICE or VNC password to be set in the UI
> >         by admin's
> >         > or power users.
> >         > Benefit: (Assumes spice SSL has been disabled) allows user
> >         or admin to
> >         > set a password for access by a standalone remote session via
> >         vncviewer
> >         > or remote-viewer or the spice html5 implementation which is
> >         WIP, or
> >         > standalone HW thin client
> >         > - This may also assume that vdsm is running with SSL
> >         disabled as well
> >         > to have had vdsm make the neccesary changes to the qemu
> >         spice
> >         > configuration
> >         
> >         
> >         Drawback: users can choose repetitive and/or weak passwords.
> >         Generating
> >         a new random password for each connection is the best thing
> >         from
> >         security POV in my opinion.
> >         
> >         >
> >         > 2) Display currently configured OR generated password and
> >         IP/Port for
> >         > either VNC or SPICE console of the VM within the PUP and
> >         Admin UI
> >         > Benefit: At the very least a standalone remote client can be
> >         used to
> >         > connect once the password and IP/PORT is known for spice or
> >         VNC
> >         >  - Currently VNC will display a dialog that shows the this
> >         info but it
> >         > would be more useful to have it displayed in the UI given
> >         proper
> >         > privilege
> >         
> >         
> >         https://bugzilla.redhat.com/show_bug.cgi?id=843397
> >         https://bugzilla.redhat.com/show_bug.cgi?id=843410
> >         
> >         >
> >         > 3) Display the UUID of a VM in the Admin UI (similar to the
> >         how the
> >         > disks tab breaks down and shows DISK UUID mappings)
> >         > - Benefit: Easier for administrators to map UUID to VM
> >         config file
> >         > data in the data stores or export domains
> >         
> >         
> >         IMO full uuid should be displayed in General subtab only
> >         because it's
> >         too long to have it as a column.
> >         
> >         It would be nice to see it in a column though in some
> >         shortened form
> >         because it could probably enable relaxing of
> >         unique-name-of-VM-in-whole-setup restriction.
> >         
> >         David
> >         
> >         >
> >         > - DHC
> >         >
> >         > _______________________________________________
> >         > Engine-devel mailing list
> >         > Engine-devel at ovirt.org
> >         > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >         
> >         --
> >         
> >         David Ja?a, RHCE
> >         
> >         SPICE QE based in Brno
> >         GPG Key:     22C33E24
> >         Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24
> >         
> >         
> >         
> > 
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> 

-- 

David Ja?a, RHCE

SPICE QE based in Brno
GPG Key:     22C33E24 
Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24





From Christopher.Morrissey at netapp.com  Fri Oct 19 13:38:41 2012
From: Christopher.Morrissey at netapp.com (Morrissey, Christopher)
Date: Fri, 19 Oct 2012 13:38:41 +0000
Subject: [Engine-devel] UI Plugins: PoC patch revision 6 now available
In-Reply-To: <803798668.9716072.1350571769692.JavaMail.root@redhat.com>
References: <115181010.9625315.1350553113828.JavaMail.root@redhat.com>
	<803798668.9716072.1350571769692.JavaMail.root@redhat.com>
Message-ID: <D290AD8432118048947689BA3AE8A9B3E9F8E0@SACEXCMBX04-PRD.hq.netapp.com>

Nice work Vojtech! I?m still in the process of pulling down the code but look forward to trying it out. Based on the descriptions of the implementations, it looks like it will give us what we need. I?ll let you know further once I get it going.

-Chris

From: engine-devel-bounces at ovirt.org [mailto:engine-devel-bounces at 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 <OVIRT_HOME>/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, but this isn't relevant in our case).

In contrast with traditional class-based object-oriented languages, JavaScript supports OOP through prototype-based programming model (https://developer.mozilla.org/en-US/docs/JavaScript/Introduction_to_Object-Oriented_JavaScript). At the same time, JavaScript language is dynamically-typed and therefore doesn't support traditional concept of interface in OOP, it uses "duck typing" technique instead (http://en.wikipedia.org/wiki/Duck_typing).

The simplest way to provide an object that "implements the given interface" in JavaScript is to use "duck typing" technique: providing an object that contains well-known functions. In UI plugin infrastructure, I call this concept "interface object", represented by org.ovirt.engine.ui.webadmin.plugin.jsni.JsInterfaceObject class. Unlike the traditional concept of interface abstract type in object-oriented languages, an "interface object" does not necessarily have to declare all functions of the given interface in order to "implement" such interface. In fact, an empty object can be used as a valid "interface object". Missing functions will be simply treated as empty (no-op) functions. Furthermore, an "interface object" can "implement" multiple interfaces by declaring functions of those interfaces (interface composition).

Getting back to "addMainTabActionButton" API, here's a sample code that adds new button to "Host" main tab data grid, as part of UiInit event handler function:

UiInit: function() {
    api.addMainTabActionButton('Host', 'Single-Host Action',

        // Action button interface object
        // All functions receive currently selected item(s) as function arguments
        {

            // Called when the user clicks the button
            onClick: function() {
                // Calling 'arguments[0]' is safe, because onClick() can be called
                // only when exactly one item is currently selected in the data grid
                window.alert('Selected host entity ID = ' + arguments[0].entityId);
            },

            // Returning 'true' means the button is enabled (clickable)
            // Returning 'false' means the button is disabled (non-clickable)
            // Default value = 'true'
            isEnabled: function() {
                // Enable button only when exactly one item is selected
                return arguments.length == 1;
            },

            // Returning 'true' means the button is visible
            // Returning 'false' means the button is hidden
            // Default value = 'true'
            isAccessible: function() {
                // Always show the button in the corresponding data grid
                return true;
            }

        }

    );
}

As mentioned above, all functions of an interface object are optional. For functions expecting return value, default value is defined by UI plugin infrastructure. For example:

  *   onClick - no default value (no return value expected)
  *   isEnabled / isAccessible - default value "true" (boolean return value expected)

Note: UI plugin infrastructure checks the actual return value type, and uses default value in case the function returned something of wrong (unexpected) type.

In the example above, "currently selected item(s)" maps to JSON-like representations of business entities currently selected in the corresponding data grid. For now, the entity representation is quite simple and same for all entity types:

{ entityId: "[BusinessEntityGuidAsString]" }

In future, we will create specific JSON-like representations for specific business entities, in compliance with Engine REST API entity structure.

For a more extensive example of using "addMainTabActionButton" API, please see the attached "addMainTabActionButton.html.example" file.
________________________________

2. Improved plugin API function: addMainTab

The "addMainTab" API was improved to address following issues:

  *   "addMainTab" can now be called at any moment during UI plugin runtime, given that the plugin is allowed invoke plugin API functions (plugin is either INITIALIZING or IN_USE).
Previously, "addMainTab" worked reliably only when called from within UiInit event handler function.
Currently, it's possible to call "addMainTab" at any moment, e.g. from within some other event handler function (after UiInit has completed).

  *   "addMainTab" now retains "active" tab (highlighted tab GUI).
"addMainTab" works by adding new tab component (GWTP presenter proxy) and refreshing main tab panel GUI by removing all related tabs and re-adding them again.
This logic is handled by org.ovirt.engine.ui.common.presenter.DynamicTabContainerPresenter class, which makes sure that "active" tab is retained even after main tab panel was refreshed.
Furthermore, custom main tab implementation now displays the content of the given URL through HTML iframe element.
________________________________

3. Improved native JavaScript function handling (GWT JSNI)

This patch introduces org.ovirt.engine.ui.webadmin.plugin.jsni.JsFunction and org.ovirt.engine.ui.webadmin.plugin.jsni.JsFunctionResultHelper classes providing Java abstraction for invoking native JavaScript functions. These classes follow the general contract of "interface object" as mentioned above.

JsFunctionResultHelper is particularly useful when dealing with functions which are expected to return value of a certain type. Too bad standard GWT JSNI classes don't provide such abstraction for working with native functions out-of-the-box...
________________________________

4. ActionPanel and ActionTable type hierarchy refactoring (related to "addMainTabActionButton" API)

Previously, AbstractActionPanel and AbstractActionTable classes didn't implement any reasonable interface that would allow other components (client-side UI plugin infrastructure) to depend on their functionality in a loosely-coupled manner. This would make code that implements "addMainTabActionButton" API "ugly": main tab view interface would have to reference AbstractActionTable class directly. In MVP design pattern, view interface should avoid referencing specific GWT Widget classes directly.

This patch introduces new interfaces for ActionPanel and ActionTable components while eliminating code redundancy (duplicate or unnecessary code).
________________________________

5. ActionPanel type hierarchy refactoring (related to "addMainTab" API)

Since org.ovirt.engine.ui.common.presenter.DynamicTabContainerPresenter defines new DynamicTabPanel interface that extends standard GWTP TabPanel interface, some refactoring had to be done in related ActionPanel classes.

This patch makes sure that both org.ovirt.engine.ui.common.widget.tab.AbstractTabPanel (widget) and org.ovirt.engine.ui.common.view.AbstractTabPanelView (view) support DynamicTabPanel interface.

Note that for now, only main tab panel (org.ovirt.engine.ui.webadmin.section.main.presenter.MainTabPanelPresenter) supports dynamic tabs within its view.
________________________________

Where is addSubTab API function?

Implementing "addSubTab" API requires some more changes, and I didn't want to delay this PoC patch just because of it...

Here's a sample code that illustrates proposed "addSubTab" API usage:

UiInit: function() {
    api.addSubTab('Host',        // entityTypeName
        'Custom Host Sub Tab',   // label
        'custom-host-sub-tab',   // historyToken
        'http://www.ovirt.org/', // contentUrl

        // Sub tab interface object
        // All functions receive currently selected item(s)
        // within the main tab data grid as function arguments
        {

            // Returning 'true' means the sub tab is visible
            // Returning 'false' means the sub tab is hidden
            // Default value = 'true'
            isAccessible: function() {
                return arguments.length == 1 && arguments[0].entityId == '<MyHostEntityId>';
            }

        }

    );
}

As part of "addSubTab" API implementation, I'll refactor custom main tab components, in order to use one "tab type" for both main and sub tabs.

Currently, we have one (and only one) "tab type" - a tab that shows content of the given URL through HTML iframe element.

We could also create new "tab types", e.g. form-based tab that shows key/value pairs (IMHO this could be quite useful for custom sub tabs).
________________________________

Let me know what you think!

Cheers,
Vojtech
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20121019/9c3b5a08/attachment.html>

From omasad at redhat.com  Sun Oct 21 08:44:13 2012
From: omasad at redhat.com (Ofri Masad)
Date: Sun, 21 Oct 2012 04:44:13 -0400 (EDT)
Subject: [Engine-devel] Quota screen casts
In-Reply-To: <678348549.4701962.1350805299923.JavaMail.root@redhat.com>
Message-ID: <1160126335.4702495.1350809053262.JavaMail.root@redhat.com>

Hi everybody.

Some new Quota screen casts have been uploaded to You-Tube.
available at: http://www.youtube.com/playlist?list=PL2NsEhIoqsJFf2HWErznfQ-CS5fQdSRGC&feature=view_all

Check out the new videos and learn about:
 - Introduction to Quota
 - Setting up Quota in oVirt 3.1 Web-Admin
 - Using Quota in oVirt 3.1 Web-Admin
 - Using Quota in oVirt 3.1 User-Portal

Ofri Masad


From mpastern at redhat.com  Sun Oct 21 10:26:46 2012
From: mpastern at redhat.com (Michael Pasternak)
Date: Sun, 21 Oct 2012 12:26:46 +0200
Subject: [Engine-devel] alias in disk instead of name
Message-ID: <5083CDE6.2090603@redhat.com>


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.

background:
==========

On 10/15/2012 02:09 PM, Einav Cohen wrote:
> we didn't exactly renamed "name" to "alias"; "name" is an automatic identifier of the disk, which is: "Disk n", n=internal drive mapping; "alias" is a *user-defined*
identifier.
>
> IIRC, once we understood that we need a user-defined identifier for the disk business entity, we indeed had in mind re-using "name", however, the "name" field in other
business entities is unique across the system, and we didn't want the disk user-defined identifier to be unique, so we preferred to not (re)use the term "name" and came up
with "alias", to avoid confusion.
>
> ----- Original Message -----
>> From: "Michael Pasternak" <mpastern at redhat.com>
>> To: "Einav Cohen" <ecohen at redhat.com>
>> Sent: Monday, October 15, 2012 1:58:26 PM
>> Subject: alias in disk instead of name
>>
>> hi,
>>
>> can you remind me why did we renamed name to alias in disk?
>>
>> --
>>
>> Michael Pasternak
>> RedHat, ENG-Virtualization R&D
>>

-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From simon at redhat.com  Sun Oct 21 13:36:02 2012
From: simon at redhat.com (Simon Grinberg)
Date: Sun, 21 Oct 2012 09:36:02 -0400 (EDT)
Subject: [Engine-devel] alias in disk instead of name
In-Reply-To: <5083CDE6.2090603@redhat.com>
Message-ID: <810633067.3351431.1350826562571.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Michael Pasternak" <mpastern at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>
> 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, thus it should not be enforced.
What would be the auto naming conversion to ensure uniqueness with plain text?
Would you change these on import/export?
And so on... 

You should treat the name as a tag/alias that if you bothered to update, probably means something to you, if not then you don't care anyhow and will not search by it anyhow. So it's up to the user what to assign.

   

> 
> background:
> ==========
> 
> On 10/15/2012 02:09 PM, Einav Cohen wrote:
> > we didn't exactly renamed "name" to "alias"; "name" is an automatic
> > identifier of the disk, which is: "Disk n", n=internal drive
> > mapping; "alias" is a *user-defined*
> identifier.
> >
> > IIRC, once we understood that we need a user-defined identifier for
> > the disk business entity, we indeed had in mind re-using "name",
> > however, the "name" field in other
> business entities is unique across the system, and we didn't want the
> disk user-defined identifier to be unique, so we preferred to not
> (re)use the term "name" and came up
> with "alias", to avoid confusion.
> >
> > ----- Original Message -----
> >> From: "Michael Pasternak" <mpastern at redhat.com>
> >> To: "Einav Cohen" <ecohen at redhat.com>
> >> Sent: Monday, October 15, 2012 1:58:26 PM
> >> Subject: alias in disk instead of name
> >>
> >> hi,
> >>
> >> can you remind me why did we renamed name to alias in disk?
> >>
> >> --
> >>
> >> Michael Pasternak
> >> RedHat, ENG-Virtualization R&D
> >>
> 
> --
> 
> Michael Pasternak
> RedHat, ENG-Virtualization R&D
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From mpastern at redhat.com  Sun Oct 21 13:48:46 2012
From: mpastern at redhat.com (Michael Pasternak)
Date: Sun, 21 Oct 2012 15:48:46 +0200
Subject: [Engine-devel] alias in disk instead of name
In-Reply-To: <810633067.3351431.1350826562571.JavaMail.root@redhat.com>
References: <810633067.3351431.1350826562571.JavaMail.root@redhat.com>
Message-ID: <5083FD3E.4020806@redhat.com>

On 10/21/2012 03:36 PM, Simon Grinberg wrote:
> 
> ----- Original Message -----
>> > From: "Michael Pasternak" <mpastern at redhat.com>
>> > To: "engine-devel" <engine-devel at ovirt.org>
>> > 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.

> 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.

> Would you change these on import/export?

would you mind elaborating on this?

> And so on... 
> 
> You should treat the name as a tag/alias that if you bothered to update, probably means something to you, if not then you don't care anyhow and will not search by it anyhow. So it's up to the user what to assign.

simon, we do not have any /name today in disk, you see it in api
for backward compatibility, actually it's emulated over /alias,

and the problem is when want to search by-name, it's not included
in backend search.

> 
>    
> 


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From simon at redhat.com  Sun Oct 21 14:15:18 2012
From: simon at redhat.com (Simon Grinberg)
Date: Sun, 21 Oct 2012 10:15:18 -0400 (EDT)
Subject: [Engine-devel] alias in disk instead of name
In-Reply-To: <5083FD3E.4020806@redhat.com>
Message-ID: <896923012.3361209.1350828918493.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Michael Pasternak" <mpastern at redhat.com>
> To: "Simon Grinberg" <simon at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> 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" <mpastern at redhat.com>
> >> > To: "engine-devel" <engine-devel at ovirt.org>
> >> > 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?  
   
> 
> > Would you change these on import/export?
> 
> would you mind elaborating on this?

Yes, 

You are already facing a problem when importing VMs that already have the same name, now you increasing the problem for disks that have the same alias. for same name we force clone if you want to import. Why for clone just because of a disk alias (this implies collapse snapshots ATM) or even bother the user with renaming disks that he does not care about the name so he just gave disk 1, 2, 3 and so on?


 
> 
> > And so on...
> > 
> > You should treat the name as a tag/alias that if you bothered to
> > update, probably means something to you, if not then you don't
> > care anyhow and will not search by it anyhow. So it's up to the
> > user what to assign.
> 
> simon, we do not have any /name today in disk, you see it in api
> for backward compatibility, actually it's emulated over /alias,

Correct, we don't have name but alias especially because we wanted to emphasize it's not unique.
But I've thought that aliases are treated like name, thus you have all the issues and suggesting to make them unique, and I'm trying to explain what we should try to avoid from having them unique. 

I agree, it's not fun when a you have 5 floating disk sharing the exact same alias - but maybe it should be the user responsibility to decide whether he is going to allow for it or not?

> 
> and the problem is when want to search by-name, it's not included
> in backend search.
> 
> > 
> >    
> > 
> 
> 
> --
> 
> Michael Pasternak
> RedHat, ENG-Virtualization R&D
> 


From danken at redhat.com  Sun Oct 21 14:42:56 2012
From: danken at redhat.com (Dan Kenigsberg)
Date: Sun, 21 Oct 2012 16:42:56 +0200
Subject: [Engine-devel] unmanaged devices thrown into 'custom' feature
Message-ID: <20121021144256.GK365@redhat.com>

I have just noticed that when a VM is started for the second time, Engine
issues the "create" vdsm verb with some information regarding
"unmanaged" devices (an example is shown below[1]) in the 'custom'
propery bag.

I'm surprised about this, as I was not aware of this usage of the
'custom' dictionary, and Vdsm is not doing anything with the data.

Would anyone elaborate about it? On the face of it, it does not seem
like a pleasant API. If Engine wants to tell Vdsm about the location of
various devices, we should probably be using the 'devices' property, not
the bag of 'custom' property made for user-defined hooks.

I hope this API pecularity can be avoided, and very much hope that no
one is depending on it.

Dan.


[1]
'custom': {
    'device_e97a9759-1c1b-45ed-9ed9-7136ef538315': 'VmDevice {vmId=068d4914-4191-400d-a220-17a7f2d8e80c, deviceId=e97a9759-1c1b-45ed-9ed9-7136ef538315, device=ide, type=controller, bootOrder=0, specParams={}, address={bus=0x00, domain=0x0000, type=pci, slot=0x01, function=0x1}, managed=false, plugged=true, readOnly=false, alias=ide0}',
    'device_e97a9759-1c1b-45ed-9ed9-7136ef538315device_133d9bfa-c531-414e-ad20-208d67d5a5e6device_7bfffa34-2e27-4b01-b499-6ac79c997709': 'VmDevice {vmId=068d4914-4191-400d-a220-17a7f2d8e80c, deviceId=7bfffa34-2e27-4b01-b499-6ac79c997709, device=unix, type=channel, bootOrder=0, specParams={}, address={port=1, bus=0, controller=0, type=virtio-serial}, managed=false, plugged=true, readOnly=false, alias=channel0}',
    'device_e97a9759-1c1b-45ed-9ed9-7136ef538315device_133d9bfa-c531-414e-ad20-208d67d5a5e6': 'VmDevice {vmId=068d4914-4191-400d-a220-17a7f2d8e80c, deviceId=133d9bfa-c531-414e-ad20-208d67d5a5e6, device=virtio-serial, type=controller, bootOrder=0, specParams={}, address={bus=0x00, domain=0x0000, type=pci, slot=0x04, function=0x0}, managed=false, plugged=true, readOnly=false, alias=virtio-serial0}',
    'device_e97a9759-1c1b-45ed-9ed9-7136ef538315device_133d9bfa-c531-414e-ad20-208d67d5a5e6device_7bfffa34-2e27-4b01-b499-6ac79c997709device_7c107c63-605f-4b21-9893-c052ec211424device_48007de9-467d-46a1-aa84-cc1a6419b5fb': 'VmDevice {vmId=068d4914-4191-400d-a220-17a7f2d8e80c, deviceId=48007de9-467d-46a1-aa84-cc1a6419b5fb, device=spicevmc, type=channel, bootOrder=0, specParams={}, address={port=3, bus=0, controller=0, type=virtio-serial}, managed=false, plugged=true, readOnly=false, alias=channel2}',
    'device_e97a9759-1c1b-45ed-9ed9-7136ef538315device_133d9bfa-c531-414e-ad20-208d67d5a5e6device_7bfffa34-2e27-4b01-b499-6ac79c997709device_7c107c63-605f-4b21-9893-c052ec211424': 'VmDevice {vmId=068d4914-4191-400d-a220-17a7f2d8e80c, deviceId=7c107c63-605f-4b21-9893-c052ec211424, device=unix, type=channel, bootOrder=0, specParams={}, address={port=2, bus=0, controller=0, type=virtio-serial}, managed=false, plugged=true, readOnly=false, alias=channel1}'
}


From mpastern at redhat.com  Sun Oct 21 14:56:33 2012
From: mpastern at redhat.com (Michael Pasternak)
Date: Sun, 21 Oct 2012 16:56:33 +0200
Subject: [Engine-devel] alias in disk instead of name
In-Reply-To: <896923012.3361209.1350828918493.JavaMail.root@redhat.com>
References: <896923012.3361209.1350828918493.JavaMail.root@redhat.com>
Message-ID: <50840D21.1070002@redhat.com>

On 10/21/2012 04:15 PM, Simon Grinberg wrote:
> 
> 
> ----- Original Message -----
>> From: "Michael Pasternak" <mpastern at redhat.com>
>> To: "Simon Grinberg" <simon at redhat.com>
>> Cc: "engine-devel" <engine-devel at ovirt.org>
>> 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" <mpastern at redhat.com>
>>>>> To: "engine-devel" <engine-devel at ovirt.org>
>>>>> 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...

>    
>>
>>> Would you change these on import/export?
>>
>> would you mind elaborating on this?
> 
> Yes, 
> 
> You are already facing a problem when importing VMs that already have the same name, now you increasing the problem for disks that have the same alias. for same name we force clone if you want to import. Why for clone just because of a disk alias (this implies collapse snapshots ATM) or even bother the user with renaming disks that he does not care about the name so he just gave disk 1, 2, 3 and so on?

i see your point, but then we leave no option for the user to locate the disk,
simply because he doesn't have unique identifier,

just imagine user A creating disk and calling it X,
then user B creating disk and calling it X, they on different
domains etc., and now both want to use disk X,

how they can figure out which one to pick?, by SD, by size? agree
this is doesn't look well..., even more than that - someone may call
this "bad design"...


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From lpeer at redhat.com  Sun Oct 21 15:18:31 2012
From: lpeer at redhat.com (Livnat Peer)
Date: Sun, 21 Oct 2012 17:18:31 +0200
Subject: [Engine-devel] unmanaged devices thrown into 'custom' feature
In-Reply-To: <20121021144256.GK365@redhat.com>
References: <20121021144256.GK365@redhat.com>
Message-ID: <50841247.5010908@redhat.com>

On 21/10/12 16:42, Dan Kenigsberg wrote:
> I have just noticed that when a VM is started for the second time, Engine
> issues the "create" vdsm verb with some information regarding
> "unmanaged" devices (an example is shown below[1]) in the 'custom'
> propery bag.
> 
> I'm surprised about this, as I was not aware of this usage of the
> 'custom' dictionary, and Vdsm is not doing anything with the data.
> 

If I recall correctly the idea of passing the unmanaged devices data in
the custom property was to enable managing stable device addresses in
the hooks (to devices that were added to the VM via hooks from the first
place), so this info is there not for VDSM use.
For example if you add a device in a hook it will be kept in the engine
as a non managed device. later when starting the VM again you would like
to assign the same device address to your device, and you can do so
because you have access to the original address in the custom properties
of the VM.



> Would anyone elaborate about it? On the face of it, it does not seem
> like a pleasant API. If Engine wants to tell Vdsm about the location of
> various devices, we should probably be using the 'devices' property, not
> the bag of 'custom' property made for user-defined hooks.
> 
> I hope this API pecularity can be avoided, and very much hope that no
> one is depending on it.
> 
> Dan.
> 
> 
> [1]
> 'custom': {
>     'device_e97a9759-1c1b-45ed-9ed9-7136ef538315': 'VmDevice {vmId=068d4914-4191-400d-a220-17a7f2d8e80c, deviceId=e97a9759-1c1b-45ed-9ed9-7136ef538315, device=ide, type=controller, bootOrder=0, specParams={}, address={bus=0x00, domain=0x0000, type=pci, slot=0x01, function=0x1}, managed=false, plugged=true, readOnly=false, alias=ide0}',
>     'device_e97a9759-1c1b-45ed-9ed9-7136ef538315device_133d9bfa-c531-414e-ad20-208d67d5a5e6device_7bfffa34-2e27-4b01-b499-6ac79c997709': 'VmDevice {vmId=068d4914-4191-400d-a220-17a7f2d8e80c, deviceId=7bfffa34-2e27-4b01-b499-6ac79c997709, device=unix, type=channel, bootOrder=0, specParams={}, address={port=1, bus=0, controller=0, type=virtio-serial}, managed=false, plugged=true, readOnly=false, alias=channel0}',
>     'device_e97a9759-1c1b-45ed-9ed9-7136ef538315device_133d9bfa-c531-414e-ad20-208d67d5a5e6': 'VmDevice {vmId=068d4914-4191-400d-a220-17a7f2d8e80c, deviceId=133d9bfa-c531-414e-ad20-208d67d5a5e6, device=virtio-serial, type=controller, bootOrder=0, specParams={}, address={bus=0x00, domain=0x0000, type=pci, slot=0x04, function=0x0}, managed=false, plugged=true, readOnly=false, alias=virtio-serial0}',
>     'device_e97a9759-1c1b-45ed-9ed9-7136ef538315device_133d9bfa-c531-414e-ad20-208d67d5a5e6device_7bfffa34-2e27-4b01-b499-6ac79c997709device_7c107c63-605f-4b21-9893-c052ec211424device_48007de9-467d-46a1-aa84-cc1a6419b5fb': 'VmDevice {vmId=068d4914-4191-400d-a220-17a7f2d8e80c, deviceId=48007de9-467d-46a1-aa84-cc1a6419b5fb, device=spicevmc, type=channel, bootOrder=0, specParams={}, address={port=3, bus=0, controller=0, type=virtio-serial}, managed=false, plugged=true, readOnly=false, alias=channel2}',
>     'device_e97a9759-1c1b-45ed-9ed9-7136ef538315device_133d9bfa-c531-414e-ad20-208d67d5a5e6device_7bfffa34-2e27-4b01-b499-6ac79c997709device_7c107c63-605f-4b21-9893-c052ec211424': 'VmDevice {vmId=068d4914-4191-400d-a220-17a7f2d8e80c, deviceId=7c107c63-605f-4b21-9893-c052ec211424, device=unix, type=channel, bootOrder=0, specParams={}, address={port=2, bus=0, controller=0, type=virtio-serial}, managed=false, plugged=true, readOnly=false, alias=channel1}'
> }
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 



From yzaslavs at redhat.com  Sun Oct 21 15:38:54 2012
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Sun, 21 Oct 2012 11:38:54 -0400 (EDT)
Subject: [Engine-devel] unmanaged devices thrown into 'custom' feature
In-Reply-To: <50841247.5010908@redhat.com>
Message-ID: <1118496200.18043280.1350833934306.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Livnat Peer" <lpeer at redhat.com>
> To: "Dan Kenigsberg" <danken at redhat.com>
> Cc: "Genadi Chereshnya" <gcheresh at redhat.com>, engine-devel at ovirt.org, vdsm-devel at fedorahosted.org
> Sent: Sunday, October 21, 2012 5:18:31 PM
> Subject: Re: [Engine-devel] unmanaged devices thrown into 'custom' feature
> 
> On 21/10/12 16:42, Dan Kenigsberg wrote:
> > I have just noticed that when a VM is started for the second time,
> > Engine
> > issues the "create" vdsm verb with some information regarding
> > "unmanaged" devices (an example is shown below[1]) in the 'custom'
> > propery bag.
> > 
> > I'm surprised about this, as I was not aware of this usage of the
> > 'custom' dictionary, and Vdsm is not doing anything with the data.
> > 
> 
> If I recall correctly the idea of passing the unmanaged devices data
> in
> the custom property was to enable managing stable device addresses in
> the hooks (to devices that were added to the VM via hooks from the
> first
> place), so this info is there not for VDSM use.
> For example if you add a device in a hook it will be kept in the
> engine
> as a non managed device. later when starting the VM again you would
> like
> to assign the same device address to your device, and you can do so
> because you have access to the original address in the custom
> properties
> of the VM.

This is exactly what Eli has explained Gendai and Dan today.
However, just to elaborate - these "extra properties" are not stored at the two columns of vm_static (userdefined_properties, predefined_properties) at the DB.

> 
> 
> 
> > Would anyone elaborate about it? On the face of it, it does not
> > seem
> > like a pleasant API. If Engine wants to tell Vdsm about the
> > location of
> > various devices, we should probably be using the 'devices'
> > property, not
> > the bag of 'custom' property made for user-defined hooks.
> > 
> > I hope this API pecularity can be avoided, and very much hope that
> > no
> > one is depending on it.
> > 
> > Dan.
> > 
> > 
> > [1]
> > 'custom': {
> >     'device_e97a9759-1c1b-45ed-9ed9-7136ef538315': 'VmDevice
> >     {vmId=068d4914-4191-400d-a220-17a7f2d8e80c,
> >     deviceId=e97a9759-1c1b-45ed-9ed9-7136ef538315, device=ide,
> >     type=controller, bootOrder=0, specParams={},
> >     address={bus=0x00, domain=0x0000, type=pci, slot=0x01,
> >     function=0x1}, managed=false, plugged=true, readOnly=false,
> >     alias=ide0}',
> >     'device_e97a9759-1c1b-45ed-9ed9-7136ef538315device_133d9bfa-c531-414e-ad20-208d67d5a5e6device_7bfffa34-2e27-4b01-b499-6ac79c997709':
> >     'VmDevice {vmId=068d4914-4191-400d-a220-17a7f2d8e80c,
> >     deviceId=7bfffa34-2e27-4b01-b499-6ac79c997709, device=unix,
> >     type=channel, bootOrder=0, specParams={}, address={port=1,
> >     bus=0, controller=0, type=virtio-serial}, managed=false,
> >     plugged=true, readOnly=false, alias=channel0}',
> >     'device_e97a9759-1c1b-45ed-9ed9-7136ef538315device_133d9bfa-c531-414e-ad20-208d67d5a5e6':
> >     'VmDevice {vmId=068d4914-4191-400d-a220-17a7f2d8e80c,
> >     deviceId=133d9bfa-c531-414e-ad20-208d67d5a5e6,
> >     device=virtio-serial, type=controller, bootOrder=0,
> >     specParams={}, address={bus=0x00, domain=0x0000, type=pci,
> >     slot=0x04, function=0x0}, managed=false, plugged=true,
> >     readOnly=false, alias=virtio-serial0}',
> >     'device_e97a9759-1c1b-45ed-9ed9-7136ef538315device_133d9bfa-c531-414e-ad20-208d67d5a5e6device_7bfffa34-2e27-4b01-b499-6ac79c997709device_7c107c63-605f-4b21-9893-c052ec211424device_48007de9-467d-46a1-aa84-cc1a6419b5fb':
> >     'VmDevice {vmId=068d4914-4191-400d-a220-17a7f2d8e80c,
> >     deviceId=48007de9-467d-46a1-aa84-cc1a6419b5fb,
> >     device=spicevmc, type=channel, bootOrder=0, specParams={},
> >     address={port=3, bus=0, controller=0, type=virtio-serial},
> >     managed=false, plugged=true, readOnly=false, alias=channel2}',
> >     'device_e97a9759-1c1b-45ed-9ed9-7136ef538315device_133d9bfa-c531-414e-ad20-208d67d5a5e6device_7bfffa34-2e27-4b01-b499-6ac79c997709device_7c107c63-605f-4b21-9893-c052ec211424':
> >     'VmDevice {vmId=068d4914-4191-400d-a220-17a7f2d8e80c,
> >     deviceId=7c107c63-605f-4b21-9893-c052ec211424, device=unix,
> >     type=channel, bootOrder=0, specParams={}, address={port=2,
> >     bus=0, controller=0, type=virtio-serial}, managed=false,
> >     plugged=true, readOnly=false, alias=channel1}'
> > }
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From emesika at redhat.com  Sun Oct 21 15:57:10 2012
From: emesika at redhat.com (Eli Mesika)
Date: Sun, 21 Oct 2012 11:57:10 -0400 (EDT)
Subject: [Engine-devel] unmanaged devices thrown into 'custom' feature
In-Reply-To: <1118496200.18043280.1350833934306.JavaMail.root@redhat.com>
Message-ID: <375751101.13843262.1350835030933.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Yair Zaslavsky" <yzaslavs at redhat.com>
> To: "Livnat Peer" <lpeer at redhat.com>
> Cc: "Genadi Chereshnya" <gcheresh at redhat.com>, engine-devel at ovirt.org, vdsm-devel at fedorahosted.org
> Sent: Sunday, October 21, 2012 5:38:54 PM
> Subject: Re: [Engine-devel] unmanaged devices thrown into 'custom' feature
> 
> 
> 
> ----- Original Message -----
> > From: "Livnat Peer" <lpeer at redhat.com>
> > To: "Dan Kenigsberg" <danken at redhat.com>
> > Cc: "Genadi Chereshnya" <gcheresh at redhat.com>,
> > engine-devel at ovirt.org, vdsm-devel at fedorahosted.org
> > Sent: Sunday, October 21, 2012 5:18:31 PM
> > Subject: Re: [Engine-devel] unmanaged devices thrown into 'custom'
> > feature
> > 
> > On 21/10/12 16:42, Dan Kenigsberg wrote:
> > > I have just noticed that when a VM is started for the second
> > > time,
> > > Engine
> > > issues the "create" vdsm verb with some information regarding
> > > "unmanaged" devices (an example is shown below[1]) in the
> > > 'custom'
> > > propery bag.
> > > 
> > > I'm surprised about this, as I was not aware of this usage of the
> > > 'custom' dictionary, and Vdsm is not doing anything with the
> > > data.
> > > 
> > 
> > If I recall correctly the idea of passing the unmanaged devices
> > data
> > in
> > the custom property was to enable managing stable device addresses
> > in
> > the hooks (to devices that were added to the VM via hooks from the
> > first
> > place), so this info is there not for VDSM use.
> > For example if you add a device in a hook it will be kept in the
> > engine
> > as a non managed device. later when starting the VM again you would
> > like
> > to assign the same device address to your device, and you can do so
> > because you have access to the original address in the custom
> > properties
> > of the VM.
> 
> This is exactly what Eli has explained Gendai and Dan today.

This is taken from the Stable Device Address design in
http://wiki.ovirt.org/wiki/Features/Design/StableDeviceAddresses

Unmanaged Device
-----------------
Unmanaged Device will be supported in the new format and will include all unhandled devices as sound/controller/etc and future devices. Those devices will be persistent and will have Type , SubType (device specific) and an Address. For 3.1 an unmanaged Device is not exposed to any GUI/REST API. Unmanaged devices are passed to vdsm inside a Custom property. VDSM in it turn is passing this as is for possible hook processing. 



> However, just to elaborate - these "extra properties" are not stored
> at the two columns of vm_static (userdefined_properties,
> predefined_properties) at the DB.
> 
> > 
> > 
> > 
> > > Would anyone elaborate about it? On the face of it, it does not
> > > seem
> > > like a pleasant API. If Engine wants to tell Vdsm about the
> > > location of
> > > various devices, we should probably be using the 'devices'
> > > property, not
> > > the bag of 'custom' property made for user-defined hooks.
> > > 
> > > I hope this API pecularity can be avoided, and very much hope
> > > that
> > > no
> > > one is depending on it.
> > > 
> > > Dan.
> > > 
> > > 
> > > [1]
> > > 'custom': {
> > >     'device_e97a9759-1c1b-45ed-9ed9-7136ef538315': 'VmDevice
> > >     {vmId=068d4914-4191-400d-a220-17a7f2d8e80c,
> > >     deviceId=e97a9759-1c1b-45ed-9ed9-7136ef538315, device=ide,
> > >     type=controller, bootOrder=0, specParams={},
> > >     address={bus=0x00, domain=0x0000, type=pci, slot=0x01,
> > >     function=0x1}, managed=false, plugged=true, readOnly=false,
> > >     alias=ide0}',
> > >     'device_e97a9759-1c1b-45ed-9ed9-7136ef538315device_133d9bfa-c531-414e-ad20-208d67d5a5e6device_7bfffa34-2e27-4b01-b499-6ac79c997709':
> > >     'VmDevice {vmId=068d4914-4191-400d-a220-17a7f2d8e80c,
> > >     deviceId=7bfffa34-2e27-4b01-b499-6ac79c997709, device=unix,
> > >     type=channel, bootOrder=0, specParams={}, address={port=1,
> > >     bus=0, controller=0, type=virtio-serial}, managed=false,
> > >     plugged=true, readOnly=false, alias=channel0}',
> > >     'device_e97a9759-1c1b-45ed-9ed9-7136ef538315device_133d9bfa-c531-414e-ad20-208d67d5a5e6':
> > >     'VmDevice {vmId=068d4914-4191-400d-a220-17a7f2d8e80c,
> > >     deviceId=133d9bfa-c531-414e-ad20-208d67d5a5e6,
> > >     device=virtio-serial, type=controller, bootOrder=0,
> > >     specParams={}, address={bus=0x00, domain=0x0000, type=pci,
> > >     slot=0x04, function=0x0}, managed=false, plugged=true,
> > >     readOnly=false, alias=virtio-serial0}',
> > >     'device_e97a9759-1c1b-45ed-9ed9-7136ef538315device_133d9bfa-c531-414e-ad20-208d67d5a5e6device_7bfffa34-2e27-4b01-b499-6ac79c997709device_7c107c63-605f-4b21-9893-c052ec211424device_48007de9-467d-46a1-aa84-cc1a6419b5fb':
> > >     'VmDevice {vmId=068d4914-4191-400d-a220-17a7f2d8e80c,
> > >     deviceId=48007de9-467d-46a1-aa84-cc1a6419b5fb,
> > >     device=spicevmc, type=channel, bootOrder=0, specParams={},
> > >     address={port=3, bus=0, controller=0, type=virtio-serial},
> > >     managed=false, plugged=true, readOnly=false,
> > >     alias=channel2}',
> > >     'device_e97a9759-1c1b-45ed-9ed9-7136ef538315device_133d9bfa-c531-414e-ad20-208d67d5a5e6device_7bfffa34-2e27-4b01-b499-6ac79c997709device_7c107c63-605f-4b21-9893-c052ec211424':
> > >     'VmDevice {vmId=068d4914-4191-400d-a220-17a7f2d8e80c,
> > >     deviceId=7c107c63-605f-4b21-9893-c052ec211424, device=unix,
> > >     type=channel, bootOrder=0, specParams={}, address={port=2,
> > >     bus=0, controller=0, type=virtio-serial}, managed=false,
> > >     plugged=true, readOnly=false, alias=channel1}'
> > > }
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > 
> > 
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From simon at redhat.com  Sun Oct 21 16:13:53 2012
From: simon at redhat.com (Simon Grinberg)
Date: Sun, 21 Oct 2012 12:13:53 -0400 (EDT)
Subject: [Engine-devel] alias in disk instead of name
In-Reply-To: <50840D21.1070002@redhat.com>
Message-ID: <11563677.3383972.1350836033792.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Michael Pasternak" <mpastern at redhat.com>
> To: "Simon Grinberg" <simon at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> 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" <mpastern at redhat.com>
> >> To: "Simon Grinberg" <simon at redhat.com>
> >> Cc: "engine-devel" <engine-devel at ovirt.org>
> >> 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" <mpastern at redhat.com>
> >>>>> To: "engine-devel" <engine-devel at ovirt.org>
> >>>>> 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 )

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. 

All that I'm saying that we can't force it's not that uniqueness in never desired. 

> 
> >    
> >>
> >>> Would you change these on import/export?
> >>
> >> would you mind elaborating on this?
> > 
> > Yes,
> > 
> > You are already facing a problem when importing VMs that already
> > have the same name, now you increasing the problem for disks that
> > have the same alias. for same name we force clone if you want to
> > import. Why for clone just because of a disk alias (this implies
> > collapse snapshots ATM) or even bother the user with renaming
> > disks that he does not care about the name so he just gave disk 1,
> > 2, 3 and so on?
> 
> i see your point, but then we leave no option for the user to locate
> the disk,
> simply because he doesn't have unique identifier,
> 
> just imagine user A creating disk and calling it X,
> then user B creating disk and calling it X, they on different
> domains etc., and now both want to use disk X,
> 
> how they can figure out which one to pick?, by SD, by size? agree
> this is doesn't look well..., even more than that - someone may call
> this "bad design"...

This is why the search should accept more then the name. 
Example (vm=name, disk=name/alias)
Example (dc=name, disk=name/alias)
Example (sd=name, disk=name/alias)
For floating/shared on the same SD/DC/VM I would suggest a warning if there is a duplicate in the system - not enforcement. 
There is a difference between best practice and being enforcing up to the level that it annoys some of the users.

> 
> 
> --
> 
> Michael Pasternak
> RedHat, ENG-Virtualization R&D
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From danken at redhat.com  Sun Oct 21 21:49:36 2012
From: danken at redhat.com (Dan Kenigsberg)
Date: Sun, 21 Oct 2012 23:49:36 +0200
Subject: [Engine-devel] unmanaged devices thrown into 'custom' feature
In-Reply-To: <375751101.13843262.1350835030933.JavaMail.root@redhat.com>
References: <1118496200.18043280.1350833934306.JavaMail.root@redhat.com>
	<375751101.13843262.1350835030933.JavaMail.root@redhat.com>
Message-ID: <20121021214936.GA7430@redhat.com>

On Sun, Oct 21, 2012 at 11:57:10AM -0400, Eli Mesika wrote:
> 
> 
> ----- Original Message -----
> > From: "Yair Zaslavsky" <yzaslavs at redhat.com>
> > To: "Livnat Peer" <lpeer at redhat.com>
> > Cc: "Genadi Chereshnya" <gcheresh at redhat.com>, engine-devel at ovirt.org, vdsm-devel at fedorahosted.org
> > Sent: Sunday, October 21, 2012 5:38:54 PM
> > Subject: Re: [Engine-devel] unmanaged devices thrown into 'custom' feature
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Livnat Peer" <lpeer at redhat.com>
> > > To: "Dan Kenigsberg" <danken at redhat.com>
> > > Cc: "Genadi Chereshnya" <gcheresh at redhat.com>,
> > > engine-devel at ovirt.org, vdsm-devel at fedorahosted.org
> > > Sent: Sunday, October 21, 2012 5:18:31 PM
> > > Subject: Re: [Engine-devel] unmanaged devices thrown into 'custom'
> > > feature
> > > 
> > > On 21/10/12 16:42, Dan Kenigsberg wrote:
> > > > I have just noticed that when a VM is started for the second
> > > > time,
> > > > Engine
> > > > issues the "create" vdsm verb with some information regarding
> > > > "unmanaged" devices (an example is shown below[1]) in the
> > > > 'custom'
> > > > propery bag.
> > > > 
> > > > I'm surprised about this, as I was not aware of this usage of the
> > > > 'custom' dictionary, and Vdsm is not doing anything with the
> > > > data.
> > > > 
> > > 
> > > If I recall correctly the idea of passing the unmanaged devices
> > > data
> > > in
> > > the custom property was to enable managing stable device addresses
> > > in
> > > the hooks (to devices that were added to the VM via hooks from the
> > > first
> > > place), so this info is there not for VDSM use.
> > > For example if you add a device in a hook it will be kept in the
> > > engine
> > > as a non managed device. later when starting the VM again you would
> > > like
> > > to assign the same device address to your device, and you can do so
> > > because you have access to the original address in the custom
> > > properties
> > > of the VM.
> > 
> > This is exactly what Eli has explained Gendai and Dan today.

(I was asking here because I did not understand the verbal explanation.)

> 
> This is taken from the Stable Device Address design in
> http://wiki.ovirt.org/wiki/Features/Design/StableDeviceAddresses
> 
> Unmanaged Device
> -----------------
> Unmanaged Device will be supported in the new format and will include all unhandled devices as sound/controller/etc and future devices. Those devices will be persistent and will have Type , SubType (device specific) and an Address. For 3.1 an unmanaged Device is not exposed to any GUI/REST API. Unmanaged devices are passed to vdsm inside a Custom property. VDSM in it turn is passing this as is for possible hook processing. 

Thanks for the elaboration. Too bad that I've missed this issue before.

Are you aware of any hook making use of this?  I hope that hook writers
are not using APIs that are not documented in vdsmd(8).

It seems as a classic case where a generic bag interface is coerced into
an awkward partially-documented interface.

I think that a better approach would have been to pass all devices
(managed and unmanaged alike) in the 'devices' property, and let vdsm
expose whatever is needed to the before_vm_start hook.

Maybe we can still do this.

Dan.


From lpeer at redhat.com  Mon Oct 22 06:29:20 2012
From: lpeer at redhat.com (Livnat Peer)
Date: Mon, 22 Oct 2012 08:29:20 +0200
Subject: [Engine-devel] [vdsm] unmanaged devices thrown into 'custom'
 feature
In-Reply-To: <20121021214936.GA7430@redhat.com>
References: <1118496200.18043280.1350833934306.JavaMail.root@redhat.com>
	<375751101.13843262.1350835030933.JavaMail.root@redhat.com>
	<20121021214936.GA7430@redhat.com>
Message-ID: <5084E7C0.8050504@redhat.com>

On 21/10/12 23:49, Dan Kenigsberg wrote:
> On Sun, Oct 21, 2012 at 11:57:10AM -0400, Eli Mesika wrote:
>>
>>
>> ----- Original Message -----
>>> From: "Yair Zaslavsky" <yzaslavs at redhat.com>
>>> To: "Livnat Peer" <lpeer at redhat.com>
>>> Cc: "Genadi Chereshnya" <gcheresh at redhat.com>, engine-devel at ovirt.org, vdsm-devel at fedorahosted.org
>>> Sent: Sunday, October 21, 2012 5:38:54 PM
>>> Subject: Re: [Engine-devel] unmanaged devices thrown into 'custom' feature
>>>
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Livnat Peer" <lpeer at redhat.com>
>>>> To: "Dan Kenigsberg" <danken at redhat.com>
>>>> Cc: "Genadi Chereshnya" <gcheresh at redhat.com>,
>>>> engine-devel at ovirt.org, vdsm-devel at fedorahosted.org
>>>> Sent: Sunday, October 21, 2012 5:18:31 PM
>>>> Subject: Re: [Engine-devel] unmanaged devices thrown into 'custom'
>>>> feature
>>>>
>>>> On 21/10/12 16:42, Dan Kenigsberg wrote:
>>>>> I have just noticed that when a VM is started for the second
>>>>> time,
>>>>> Engine
>>>>> issues the "create" vdsm verb with some information regarding
>>>>> "unmanaged" devices (an example is shown below[1]) in the
>>>>> 'custom'
>>>>> propery bag.
>>>>>
>>>>> I'm surprised about this, as I was not aware of this usage of the
>>>>> 'custom' dictionary, and Vdsm is not doing anything with the
>>>>> data.
>>>>>
>>>>
>>>> If I recall correctly the idea of passing the unmanaged devices
>>>> data
>>>> in
>>>> the custom property was to enable managing stable device addresses
>>>> in
>>>> the hooks (to devices that were added to the VM via hooks from the
>>>> first
>>>> place), so this info is there not for VDSM use.
>>>> For example if you add a device in a hook it will be kept in the
>>>> engine
>>>> as a non managed device. later when starting the VM again you would
>>>> like
>>>> to assign the same device address to your device, and you can do so
>>>> because you have access to the original address in the custom
>>>> properties
>>>> of the VM.
>>>
>>> This is exactly what Eli has explained Gendai and Dan today.
> 
> (I was asking here because I did not understand the verbal explanation.)
> 
>>
>> This is taken from the Stable Device Address design in
>> http://wiki.ovirt.org/wiki/Features/Design/StableDeviceAddresses
>>
>> Unmanaged Device
>> -----------------
>> Unmanaged Device will be supported in the new format and will include all unhandled devices as sound/controller/etc and future devices. Those devices will be persistent and will have Type , SubType (device specific) and an Address. For 3.1 an unmanaged Device is not exposed to any GUI/REST API. Unmanaged devices are passed to vdsm inside a Custom property. VDSM in it turn is passing this as is for possible hook processing. 
> 
> Thanks for the elaboration. Too bad that I've missed this issue before.
> 
> Are you aware of any hook making use of this?  I hope that hook writers
> are not using APIs that are not documented in vdsmd(8).
> 
> It seems as a classic case where a generic bag interface is coerced into
> an awkward partially-documented interface.
> 
> I think that a better approach would have been to pass all devices
> (managed and unmanaged alike) in the 'devices' property, and let vdsm
> expose whatever is needed to the before_vm_start hook.
> 
> Maybe we can still do this.

That was the original idea but Ayal objected and I think Igor did not
like it as well...


> 
> Dan.
> _______________________________________________
> vdsm-devel mailing list
> vdsm-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
> 



From mpastern at redhat.com  Mon Oct 22 06:58:25 2012
From: mpastern at redhat.com (Michael Pasternak)
Date: Mon, 22 Oct 2012 08:58:25 +0200
Subject: [Engine-devel] alias in disk instead of name
In-Reply-To: <11563677.3383972.1350836033792.JavaMail.root@redhat.com>
References: <11563677.3383972.1350836033792.JavaMail.root@redhat.com>
Message-ID: <5084EE91.7020602@redhat.com>

On 10/21/2012 06:13 PM, Simon Grinberg wrote:
> 
> 
> ----- Original Message -----
>> From: "Michael Pasternak" <mpastern at redhat.com>
>> To: "Simon Grinberg" <simon at redhat.com>
>> Cc: "engine-devel" <engine-devel at ovirt.org>
>> 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" <mpastern at redhat.com>
>>>> To: "Simon Grinberg" <simon at redhat.com>
>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
>>>> 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" <mpastern at redhat.com>
>>>>>>> To: "engine-devel" <engine-devel at ovirt.org>
>>>>>>> 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 ...

> 
> 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.

> 
> 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 talking about /search,
search is available only at /api/disks (i.e shared disks, vm/template.disks is
irrelevant to this discussion)

> 
>>
>>>    
>>>>
>>>>> Would you change these on import/export?
>>>>
>>>> would you mind elaborating on this?
>>>
>>> Yes,
>>>
>>> You are already facing a problem when importing VMs that already
>>> have the same name, now you increasing the problem for disks that
>>> have the same alias. for same name we force clone if you want to
>>> import. Why for clone just because of a disk alias (this implies
>>> collapse snapshots ATM) or even bother the user with renaming
>>> disks that he does not care about the name so he just gave disk 1,
>>> 2, 3 and so on?
>>
>> i see your point, but then we leave no option for the user to locate
>> the disk,
>> simply because he doesn't have unique identifier,
>>
>> just imagine user A creating disk and calling it X,
>> then user B creating disk and calling it X, they on different
>> domains etc., and now both want to use disk X,
>>
>> how they can figure out which one to pick?, by SD, by size? agree
>> this is doesn't look well..., even more than that - someone may call
>> this "bad design"...
> 
> This is why the search should accept more then the name. 
> Example (vm=name, disk=name/alias)
> Example (dc=name, disk=name/alias)
> Example (sd=name, disk=name/alias)

it's not about accepting both name/alias, it's about missing ability
to identify your resource in collection.

> For floating/shared on the same SD/DC/VM I would suggest a warning if there is a duplicate in the system - not enforcement. 

ok, lets assume we WARN user that his disk's name is not unique, how user will pick the unique name?
implementing own code checking if new name (he wants to use) is unique or not?

- this is business logic, not user's prerogative.

> There is a difference between best practice and being enforcing up to the level that it annoys some of the users.

simon, when you register to email, you have to try N times till you find unique username,
is it convenient? absolutely NO, is it annoying? YES, but you forced doing that so
system will be able to identify you,

it's no different in any way, good software protects user/itself even in cost of convenience,

bottom line
===========

- i think as long as disk not shared/floating it can have any name
- in a minute disk designation changed to shared, name uniqueness should be forced (by the engine)
- when importing vm with shared disks, name uniqueness should be forced
- when creating vm from template with shared disk, name uniqueness should be forced
- alias should be changed back to name (in sake of consistency)
- /api/disks collection should support searching disks by name (in sake of consistency)


thoughts?

> 
>>
>>
>> --
>>
>> Michael Pasternak
>> RedHat, ENG-Virtualization R&D
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From simon at redhat.com  Mon Oct 22 08:50:02 2012
From: simon at redhat.com (Simon Grinberg)
Date: Mon, 22 Oct 2012 04:50:02 -0400 (EDT)
Subject: [Engine-devel] alias in disk instead of name
In-Reply-To: <5084EE91.7020602@redhat.com>
Message-ID: <837208046.3632243.1350895802861.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Michael Pasternak" <mpastern at redhat.com>
> To: "Simon Grinberg" <simon at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> 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" <mpastern at redhat.com>
> >> To: "Simon Grinberg" <simon at redhat.com>
> >> Cc: "engine-devel" <engine-devel at ovirt.org>
> >> 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" <mpastern at redhat.com>
> >>>> To: "Simon Grinberg" <simon at redhat.com>
> >>>> Cc: "engine-devel" <engine-devel at ovirt.org>
> >>>> 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" <mpastern at redhat.com>
> >>>>>>> To: "engine-devel" <engine-devel at ovirt.org>
> >>>>>>> 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 talking about /search,
> search is available only at /api/disks (i.e shared disks,
> vm/template.disks is
> irrelevant to this discussion)

Nope I do not, but I think that our perspectives differ.
You are looking at it as strictly design issue. You have a collection of entities and you want a human readable search, thus you are trying to force (rightfully) from your point of view a unique alias/name for those. 

I taking the end user perspective, and user experience 
1. Majority of the disks have no meaning outside of a VM scope.
2. There are fractions of the disks that are usually shared (this is the nature of shared disks)
3. There are fractions of floating, most of the floating will be a transient state, while you are moving disks around. 

What I'm trying to say that forcing a user to provide a unique name per disk is a huge bother. 
And again in the multi tenancy case, you can't enforce a unique alias in the system.

What will you say to the user in the error message? 
Sorry you can't use this alias since another user that is sharing the system with you already provided that name? And yes we know you can't see that other disk, and it you don't care about the other user, but still you can't use your alias since this is how our platform designed.

The meaning is that you must allow a for a more sophisticated search. Yes even in the context of the disks tab. Disks are not really stand alone entities, and if we keep to strict conventions like - in any collection an entity name must be unique, then you are making the system hardly usable for many users. 

So a search in disks should include other 'properties' (and yes I know those are not disk properties, but this is how a user will look at it) like owner,quota,vm,storage domain, etc. 

To some up - what should be unique are UUIDs of an entities, and infrastructure entities names (within the same scope) - all the rest must not.


> 
> > 
> >>
> >>>    
> >>>>
> >>>>> Would you change these on import/export?
> >>>>
> >>>> would you mind elaborating on this?
> >>>
> >>> Yes,
> >>>
> >>> You are already facing a problem when importing VMs that already
> >>> have the same name, now you increasing the problem for disks that
> >>> have the same alias. for same name we force clone if you want to
> >>> import. Why for clone just because of a disk alias (this implies
> >>> collapse snapshots ATM) or even bother the user with renaming
> >>> disks that he does not care about the name so he just gave disk
> >>> 1,
> >>> 2, 3 and so on?
> >>
> >> i see your point, but then we leave no option for the user to
> >> locate
> >> the disk,
> >> simply because he doesn't have unique identifier,
> >>
> >> just imagine user A creating disk and calling it X,
> >> then user B creating disk and calling it X, they on different
> >> domains etc., and now both want to use disk X,
> >>
> >> how they can figure out which one to pick?, by SD, by size? agree
> >> this is doesn't look well..., even more than that - someone may
> >> call
> >> this "bad design"...
> > 
> > This is why the search should accept more then the name.
> > Example (vm=name, disk=name/alias)
> > Example (dc=name, disk=name/alias)
> > Example (sd=name, disk=name/alias)
> 
> it's not about accepting both name/alias, it's about missing ability
> to identify your resource in collection.
> 
> > For floating/shared on the same SD/DC/VM I would suggest a warning
> > if there is a duplicate in the system - not enforcement.
> 
> ok, lets assume we WARN user that his disk's name is not unique, how
> user will pick the unique name?
> implementing own code checking if new name (he wants to use) is
> unique or not?
> 
> - this is business logic, not user's prerogative.
> 
> > There is a difference between best practice and being enforcing up
> > to the level that it annoys some of the users.
> 
> simon, when you register to email, you have to try N times till you
> find unique username,
> is it convenient? absolutely NO, is it annoying? YES, but you forced
> doing that so
> system will be able to identify you,
> 
> it's no different in any way, good software protects user/itself even
> in cost of convenience,
> 
> bottom line
> ===========
> 
> - i think as long as disk not shared/floating it can have any name
> - in a minute disk designation changed to shared, name uniqueness
> should be forced (by the engine)
> - when importing vm with shared disks, name uniqueness should be
> forced
> - when creating vm from template with shared disk, name uniqueness
> should be forced
> - alias should be changed back to name (in sake of consistency)
> - /api/disks collection should support searching disks by name (in
> sake of consistency)
> 
> 
> thoughts?

Please look at the previous comment, that just can't work in the multi-tenancy case.
Name should not be unique, the warning is for the admin only, from the user portal a warning should be issues only if the user provides same name twice.


> 
> > 
> >>
> >>
> >> --
> >>
> >> Michael Pasternak
> >> RedHat, ENG-Virtualization R&D
> >> _______________________________________________
> >> Engine-devel mailing list
> >> Engine-devel at ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>
> 
> 
> --
> 
> Michael Pasternak
> RedHat, ENG-Virtualization R&D
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From deepakcs at linux.vnet.ibm.com  Mon Oct 22 11:01:58 2012
From: deepakcs at linux.vnet.ibm.com (Deepak C Shetty)
Date: Mon, 22 Oct 2012 16:31:58 +0530
Subject: [Engine-devel] Feature page for GLUSTERFS_DOMAIN support is now
	available.
In-Reply-To: <508526A7.2050001@linux.vnet.ibm.com>
References: <508526A7.2050001@linux.vnet.ibm.com>
Message-ID: <508527A6.2070109@linux.vnet.ibm.com>

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






From Christopher.Morrissey at netapp.com  Mon Oct 22 15:25:53 2012
From: Christopher.Morrissey at netapp.com (Morrissey, Christopher)
Date: Mon, 22 Oct 2012 15:25:53 +0000
Subject: [Engine-devel] UI Plugins: PoC patch revision 6 now available
In-Reply-To: <803798668.9716072.1350571769692.JavaMail.root@redhat.com>
References: <115181010.9625315.1350553113828.JavaMail.root@redhat.com>
	<803798668.9716072.1350571769692.JavaMail.root@redhat.com>
Message-ID: <D290AD8432118048947689BA3AE8A9B3EA0073@SACEXCMBX04-PRD.hq.netapp.com>

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.

-Chris

From: engine-devel-bounces at ovirt.org [mailto:engine-devel-bounces at 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 <OVIRT_HOME>/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, but this isn't relevant in our case).

In contrast with traditional class-based object-oriented languages, JavaScript supports OOP through prototype-based programming model (https://developer.mozilla.org/en-US/docs/JavaScript/Introduction_to_Object-Oriented_JavaScript). At the same time, JavaScript language is dynamically-typed and therefore doesn't support traditional concept of interface in OOP, it uses "duck typing" technique instead (http://en.wikipedia.org/wiki/Duck_typing).

The simplest way to provide an object that "implements the given interface" in JavaScript is to use "duck typing" technique: providing an object that contains well-known functions. In UI plugin infrastructure, I call this concept "interface object", represented by org.ovirt.engine.ui.webadmin.plugin.jsni.JsInterfaceObject class. Unlike the traditional concept of interface abstract type in object-oriented languages, an "interface object" does not necessarily have to declare all functions of the given interface in order to "implement" such interface. In fact, an empty object can be used as a valid "interface object". Missing functions will be simply treated as empty (no-op) functions. Furthermore, an "interface object" can "implement" multiple interfaces by declaring functions of those interfaces (interface composition).

Getting back to "addMainTabActionButton" API, here's a sample code that adds new button to "Host" main tab data grid, as part of UiInit event handler function:

UiInit: function() {
    api.addMainTabActionButton('Host', 'Single-Host Action',

        // Action button interface object
        // All functions receive currently selected item(s) as function arguments
        {

            // Called when the user clicks the button
            onClick: function() {
                // Calling 'arguments[0]' is safe, because onClick() can be called
                // only when exactly one item is currently selected in the data grid
                window.alert('Selected host entity ID = ' + arguments[0].entityId);
            },

            // Returning 'true' means the button is enabled (clickable)
            // Returning 'false' means the button is disabled (non-clickable)
            // Default value = 'true'
            isEnabled: function() {
                // Enable button only when exactly one item is selected
                return arguments.length == 1;
            },

            // Returning 'true' means the button is visible
            // Returning 'false' means the button is hidden
            // Default value = 'true'
            isAccessible: function() {
                // Always show the button in the corresponding data grid
                return true;
            }

        }

    );
}

As mentioned above, all functions of an interface object are optional. For functions expecting return value, default value is defined by UI plugin infrastructure. For example:

  *   onClick - no default value (no return value expected)
  *   isEnabled / isAccessible - default value "true" (boolean return value expected)

Note: UI plugin infrastructure checks the actual return value type, and uses default value in case the function returned something of wrong (unexpected) type.

In the example above, "currently selected item(s)" maps to JSON-like representations of business entities currently selected in the corresponding data grid. For now, the entity representation is quite simple and same for all entity types:

{ entityId: "[BusinessEntityGuidAsString]" }

In future, we will create specific JSON-like representations for specific business entities, in compliance with Engine REST API entity structure.

For a more extensive example of using "addMainTabActionButton" API, please see the attached "addMainTabActionButton.html.example" file.
________________________________

2. Improved plugin API function: addMainTab

The "addMainTab" API was improved to address following issues:

  *   "addMainTab" can now be called at any moment during UI plugin runtime, given that the plugin is allowed invoke plugin API functions (plugin is either INITIALIZING or IN_USE).
Previously, "addMainTab" worked reliably only when called from within UiInit event handler function.
Currently, it's possible to call "addMainTab" at any moment, e.g. from within some other event handler function (after UiInit has completed).

  *   "addMainTab" now retains "active" tab (highlighted tab GUI).
"addMainTab" works by adding new tab component (GWTP presenter proxy) and refreshing main tab panel GUI by removing all related tabs and re-adding them again.
This logic is handled by org.ovirt.engine.ui.common.presenter.DynamicTabContainerPresenter class, which makes sure that "active" tab is retained even after main tab panel was refreshed.
Furthermore, custom main tab implementation now displays the content of the given URL through HTML iframe element.
________________________________

3. Improved native JavaScript function handling (GWT JSNI)

This patch introduces org.ovirt.engine.ui.webadmin.plugin.jsni.JsFunction and org.ovirt.engine.ui.webadmin.plugin.jsni.JsFunctionResultHelper classes providing Java abstraction for invoking native JavaScript functions. These classes follow the general contract of "interface object" as mentioned above.

JsFunctionResultHelper is particularly useful when dealing with functions which are expected to return value of a certain type. Too bad standard GWT JSNI classes don't provide such abstraction for working with native functions out-of-the-box...
________________________________

4. ActionPanel and ActionTable type hierarchy refactoring (related to "addMainTabActionButton" API)

Previously, AbstractActionPanel and AbstractActionTable classes didn't implement any reasonable interface that would allow other components (client-side UI plugin infrastructure) to depend on their functionality in a loosely-coupled manner. This would make code that implements "addMainTabActionButton" API "ugly": main tab view interface would have to reference AbstractActionTable class directly. In MVP design pattern, view interface should avoid referencing specific GWT Widget classes directly.

This patch introduces new interfaces for ActionPanel and ActionTable components while eliminating code redundancy (duplicate or unnecessary code).
________________________________

5. ActionPanel type hierarchy refactoring (related to "addMainTab" API)

Since org.ovirt.engine.ui.common.presenter.DynamicTabContainerPresenter defines new DynamicTabPanel interface that extends standard GWTP TabPanel interface, some refactoring had to be done in related ActionPanel classes.

This patch makes sure that both org.ovirt.engine.ui.common.widget.tab.AbstractTabPanel (widget) and org.ovirt.engine.ui.common.view.AbstractTabPanelView (view) support DynamicTabPanel interface.

Note that for now, only main tab panel (org.ovirt.engine.ui.webadmin.section.main.presenter.MainTabPanelPresenter) supports dynamic tabs within its view.
________________________________

Where is addSubTab API function?

Implementing "addSubTab" API requires some more changes, and I didn't want to delay this PoC patch just because of it...

Here's a sample code that illustrates proposed "addSubTab" API usage:

UiInit: function() {
    api.addSubTab('Host',        // entityTypeName
        'Custom Host Sub Tab',   // label
        'custom-host-sub-tab',   // historyToken
        'http://www.ovirt.org/', // contentUrl

        // Sub tab interface object
        // All functions receive currently selected item(s)
        // within the main tab data grid as function arguments
        {

            // Returning 'true' means the sub tab is visible
            // Returning 'false' means the sub tab is hidden
            // Default value = 'true'
            isAccessible: function() {
                return arguments.length == 1 && arguments[0].entityId == '<MyHostEntityId>';
            }

        }

    );
}

As part of "addSubTab" API implementation, I'll refactor custom main tab components, in order to use one "tab type" for both main and sub tabs.

Currently, we have one (and only one) "tab type" - a tab that shows content of the given URL through HTML iframe element.

We could also create new "tab types", e.g. form-based tab that shows key/value pairs (IMHO this could be quite useful for custom sub tabs).
________________________________

Let me know what you think!

Cheers,
Vojtech
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20121022/f1b6b76c/attachment.html>

From agl at us.ibm.com  Mon Oct 22 19:22:18 2012
From: agl at us.ibm.com (Adam Litke)
Date: Mon, 22 Oct 2012 14:22:18 -0500
Subject: [Engine-devel] Strange input from oVirt-engine for create (VM) API
Message-ID: <20121022192218.GU3672@aglitke>

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 <agl at us.ibm.com>
IBM Linux Technology Center



From danken at redhat.com  Mon Oct 22 20:51:52 2012
From: danken at redhat.com (Dan Kenigsberg)
Date: Mon, 22 Oct 2012 22:51:52 +0200
Subject: [Engine-devel] [vdsm] Strange input from oVirt-engine for
	create (VM) API
In-Reply-To: <20121022192218.GU3672@aglitke>
References: <20121022192218.GU3672@aglitke>
Message-ID: <20121022205152.GC28858@redhat.com>

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.


From smizrahi at redhat.com  Mon Oct 22 21:32:01 2012
From: smizrahi at redhat.com (Saggi Mizrahi)
Date: Mon, 22 Oct 2012 17:32:01 -0400 (EDT)
Subject: [Engine-devel] git-review
In-Reply-To: <1463939213.11041255.1350940567913.JavaMail.root@redhat.com>
Message-ID: <237875529.11045873.1350941521163.JavaMail.root@redhat.com>

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


From iheim at redhat.com  Tue Oct 23 06:49:02 2012
From: iheim at redhat.com (Itamar Heim)
Date: Tue, 23 Oct 2012 08:49:02 +0200
Subject: [Engine-devel] UI Plugins: PoC patch revision 6 now available
In-Reply-To: <D290AD8432118048947689BA3AE8A9B3EA0073@SACEXCMBX04-PRD.hq.netapp.com>
References: <115181010.9625315.1350553113828.JavaMail.root@redhat.com>
	<803798668.9716072.1350571769692.JavaMail.root@redhat.com>
	<D290AD8432118048947689BA3AE8A9B3EA0073@SACEXCMBX04-PRD.hq.netapp.com>
Message-ID: <50863DDE.4020906@redhat.com>

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-bounces at ovirt.org
> [mailto:engine-devel-bounces at 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 <OVIRT_HOME>/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, but this isn't relevant in our case).
>
> In contrast with traditional class-based object-oriented languages,
> JavaScript supports OOP through prototype-based programming model
> (https://developer.mozilla.org/en-US/docs/JavaScript/Introduction_to_Object-Oriented_JavaScript).
> At the same time, JavaScript language is dynamically-typed and therefore
> doesn't support traditional concept of interface in OOP, it uses "duck
> typing" technique instead (http://en.wikipedia.org/wiki/Duck_typing).
>
> The simplest way to provide an object that "implements the given
> interface" in JavaScript is to use "duck typing" technique: providing an
> object that contains well-known functions. In UI plugin infrastructure,
> I call this concept "interface object", represented by
> org.ovirt.engine.ui.webadmin.plugin.jsni.JsInterfaceObject class. Unlike
> the traditional concept of interface abstract type in object-oriented
> languages, an "interface object" _does not necessarily have to declare
> all functions of the given interface_ in order to "implement" such
> interface. In fact, an empty object can be used as a valid "interface
> object". Missing functions will be simply treated as empty (no-op)
> functions. Furthermore, an "interface object" can "implement" multiple
> interfaces by declaring functions of those interfaces (interface
> composition).
>
> Getting back to "addMainTabActionButton" API, here's a sample code that
> adds new button to "Host" main tab data grid, as part of UiInit event
> handler function:
>
> UiInit: *function*() {
>      api.addMainTabActionButton('Host', 'Single-Host Action',
>
>          // Action button interface object
>          // All functions receive currently selected item(s) as function
> arguments
>          {
>
>              // Called when the user clicks the button
> onClick: *function*() {
>                  // Calling 'arguments[0]' is safe, because onClick()
> can be called
>                  // only when exactly one item is currently selected in
> the data grid
>                  window.alert('Selected host entity ID = ' +
> arguments[0].entityId);
>              },
>
>              // Returning 'true' means the button is enabled (clickable)
>              // Returning 'false' means the button is disabled
> (non-clickable)
>              // Default value = 'true'
> isEnabled: *function*() {
>                  // Enable button only when exactly one item is selected
> *return*arguments.length == 1;
>              },
>
>              // Returning 'true' means the button is visible
>              // Returning 'false' means the button is hidden
>              // Default value = 'true'
> isAccessible: *function*() {
>                  // Always show the button in the corresponding data grid
> *return**true*;
>              }
>
>          }
>
>      );
> }
>
> As mentioned above, all functions of an interface object are optional.
> For functions expecting return value, default value is defined by UI
> plugin infrastructure. For example:
>
>   * onClick - no default value (no return value expected)
>   * isEnabled / isAccessible - default value "true" (boolean return
>     value expected)
>
> Note: UI plugin infrastructure checks the actual return value type, and
> uses default value in case the function returned something of wrong
> (unexpected) type.
>
>
> In the example above, "currently selected item(s)" maps to JSON-like
> representations of business entities currently selected in the
> corresponding data grid. For now, the entity representation is quite
> simple and same for all entity types:
>
> { entityId: "[BusinessEntityGuidAsString]" }
>
> In future, we will create specific JSON-like representations for
> specific business entities, in compliance with Engine REST API entity
> structure.
>
> For a more extensive example of using "addMainTabActionButton" API,
> please see the attached "addMainTabActionButton.html.example" file.
>
> ------------------------------------------------------------------------
>
>
> *2. Improved plugin API function: addMainTab
> *
> The "addMainTab" API was improved to address following issues:
>
>   * "addMainTab" can now be called at any moment during UI plugin
>     runtime, given that the plugin is allowed invoke plugin API
>     functions (plugin is either INITIALIZING or IN_USE).
>     Previously, "addMainTab" worked reliably only when called from
>     within UiInit event handler function.
>     Currently, it's possible to call "addMainTab" at any moment, e.g.
>     from within some other event handler function (after UiInit has
>     completed).
>
>   * "addMainTab" now retains "active" tab (highlighted tab GUI).
>     "addMainTab" works by adding new tab component (GWTP presenter
>     proxy) and refreshing main tab panel GUI by removing all related
>     tabs and re-adding them again.
>     This logic is handled by
>     org.ovirt.engine.ui.common.presenter.DynamicTabContainerPresenter
>     class, which makes sure that "active" tab is retained even after
>     main tab panel was refreshed.
>
> Furthermore, custom main tab implementation now displays the content of
> the given URL through HTML iframe element.
>
> ------------------------------------------------------------------------
>
>
> *3. Improved native JavaScript function handling* (GWT JSNI)
>
> This patch introduces
> org.ovirt.engine.ui.webadmin.plugin.jsni.JsFunction and
> org.ovirt.engine.ui.webadmin.plugin.jsni.JsFunctionResultHelper classes
> providing Java abstraction for invoking native JavaScript functions.
> These classes follow the general contract of "interface object" as
> mentioned above.
>
> JsFunctionResultHelper is particularly useful when dealing with
> functions which are expected to return value of a certain type. Too bad
> standard GWT JSNI classes don't provide such abstraction for working
> with native functions out-of-the-box...
>
> ------------------------------------------------------------------------
>
>
> *4. ActionPanel and ActionTable type hierarchy refactoring* (related to
> "addMainTabActionButton" API)*
> *
> Previously, AbstractActionPanel and AbstractActionTable classes didn't
> implement any reasonable interface that would allow other components
> (client-side UI plugin infrastructure) to depend on their functionality
> in a loosely-coupled manner. This would make code that implements
> "addMainTabActionButton" API "ugly": main tab view interface would have
> to reference AbstractActionTable class directly. In MVP design pattern,
> view interface should avoid referencing specific GWT Widget classes
> directly.
>
> This patch introduces new interfaces for ActionPanel and ActionTable
> components while eliminating code redundancy (duplicate or unnecessary
> code).
>
> ------------------------------------------------------------------------
>
>
> *5. ActionPanel type hierarchy refactoring* (related to "addMainTab" API)
>
> Since org.ovirt.engine.ui.common.presenter.DynamicTabContainerPresenter
> defines new DynamicTabPanel interface that extends standard GWTP
> TabPanel interface, some refactoring had to be done in related
> ActionPanel classes.
>
> This patch makes sure that both
> org.ovirt.engine.ui.common.widget.tab.AbstractTabPanel (widget) and
> org.ovirt.engine.ui.common.view.AbstractTabPanelView (view) support
> DynamicTabPanel interface.
>
> Note that for now, only main tab panel
> (org.ovirt.engine.ui.webadmin.section.main.presenter.MainTabPanelPresenter)
> supports dynamic tabs within its view.
>
> ------------------------------------------------------------------------
>
>
> *Where is addSubTab API function?*
>
> Implementing "addSubTab" API requires some more changes, and I didn't
> want to delay this PoC patch just because of it...
>
> Here's a sample code that illustrates proposed "addSubTab" API usage:
>
> UiInit: *function*() {
>      api.addSubTab('Host', // entityTypeName
>          'Custom Host Sub Tab', // label
>          'custom-host-sub-tab', // historyToken
>          'http://www.ovirt.org/', // contentUrl
>
> // Sub tab interface object
>          // All functions receive currently selected item(s)
>          // within the main tab data grid as function arguments
>          {
>
>              // Returning 'true' means the sub tab is visible
>              // Returning 'false' means the sub tab is hidden
>              // Default value = 'true'
> isAccessible: *function*() {
> *return*arguments.length == 1 && arguments[0].entityId ==
> '<MyHostEntityId>';
>              }
>
>          }
>
>      );
> }
>
> As part of "addSubTab" API implementation, I'll refactor custom main tab
> components, in order to use one "tab type" for both main and sub tabs.
>
> Currently, we have one (and only one) "tab type" - a tab that shows
> content of the given URL through HTML iframe element.
>
> We could also create new "tab types", e.g. form-based tab that shows
> key/value pairs (IMHO this could be quite useful for custom sub tabs).
>
> ------------------------------------------------------------------------
>
>
> Let me know what you think!
>
> Cheers,
> Vojtech
>
>
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>




From simon at redhat.com  Tue Oct 23 08:36:53 2012
From: simon at redhat.com (Simon Grinberg)
Date: Tue, 23 Oct 2012 04:36:53 -0400 (EDT)
Subject: [Engine-devel] alias in disk instead of name
In-Reply-To: <837208046.3632243.1350895802861.JavaMail.root@redhat.com>
Message-ID: <1592047120.4617768.1350981413665.JavaMail.root@redhat.com>

Hey all, 

We need more thoughts here from others, there are two different approaches on the table and more opinions are welcomed.
If there are API consumers on this list then your view is more then welcomed. 

Thanks, 
Simon.

----- Original Message -----
> From: "Simon Grinberg" <simon at redhat.com>
> To: "Michael Pasternak" <mpastern at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Monday, October 22, 2012 10:50:02 AM
> Subject: Re: [Engine-devel] alias in disk instead of name
> 
> 
> 
> ----- Original Message -----
> > From: "Michael Pasternak" <mpastern at redhat.com>
> > To: "Simon Grinberg" <simon at redhat.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>
> > 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" <mpastern at redhat.com>
> > >> To: "Simon Grinberg" <simon at redhat.com>
> > >> Cc: "engine-devel" <engine-devel at ovirt.org>
> > >> 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" <mpastern at redhat.com>
> > >>>> To: "Simon Grinberg" <simon at redhat.com>
> > >>>> Cc: "engine-devel" <engine-devel at ovirt.org>
> > >>>> 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" <mpastern at redhat.com>
> > >>>>>>> To: "engine-devel" <engine-devel at ovirt.org>
> > >>>>>>> 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 talking about /search,
> > search is available only at /api/disks (i.e shared disks,
> > vm/template.disks is
> > irrelevant to this discussion)
> 
> Nope I do not, but I think that our perspectives differ.
> You are looking at it as strictly design issue. You have a collection
> of entities and you want a human readable search, thus you are
> trying to force (rightfully) from your point of view a unique
> alias/name for those.
> 
> I taking the end user perspective, and user experience
> 1. Majority of the disks have no meaning outside of a VM scope.
> 2. There are fractions of the disks that are usually shared (this is
> the nature of shared disks)
> 3. There are fractions of floating, most of the floating will be a
> transient state, while you are moving disks around.
> 
> What I'm trying to say that forcing a user to provide a unique name
> per disk is a huge bother.
> And again in the multi tenancy case, you can't enforce a unique alias
> in the system.
> 
> What will you say to the user in the error message?
> Sorry you can't use this alias since another user that is sharing the
> system with you already provided that name? And yes we know you
> can't see that other disk, and it you don't care about the other
> user, but still you can't use your alias since this is how our
> platform designed.
> 
> The meaning is that you must allow a for a more sophisticated search.
> Yes even in the context of the disks tab. Disks are not really stand
> alone entities, and if we keep to strict conventions like - in any
> collection an entity name must be unique, then you are making the
> system hardly usable for many users.
> 
> So a search in disks should include other 'properties' (and yes I
> know those are not disk properties, but this is how a user will look
> at it) like owner,quota,vm,storage domain, etc.
> 
> To some up - what should be unique are UUIDs of an entities, and
> infrastructure entities names (within the same scope) - all the rest
> must not.
> 
> 
> > 
> > > 
> > >>
> > >>>    
> > >>>>
> > >>>>> Would you change these on import/export?
> > >>>>
> > >>>> would you mind elaborating on this?
> > >>>
> > >>> Yes,
> > >>>
> > >>> You are already facing a problem when importing VMs that
> > >>> already
> > >>> have the same name, now you increasing the problem for disks
> > >>> that
> > >>> have the same alias. for same name we force clone if you want
> > >>> to
> > >>> import. Why for clone just because of a disk alias (this
> > >>> implies
> > >>> collapse snapshots ATM) or even bother the user with renaming
> > >>> disks that he does not care about the name so he just gave disk
> > >>> 1,
> > >>> 2, 3 and so on?
> > >>
> > >> i see your point, but then we leave no option for the user to
> > >> locate
> > >> the disk,
> > >> simply because he doesn't have unique identifier,
> > >>
> > >> just imagine user A creating disk and calling it X,
> > >> then user B creating disk and calling it X, they on different
> > >> domains etc., and now both want to use disk X,
> > >>
> > >> how they can figure out which one to pick?, by SD, by size?
> > >> agree
> > >> this is doesn't look well..., even more than that - someone may
> > >> call
> > >> this "bad design"...
> > > 
> > > This is why the search should accept more then the name.
> > > Example (vm=name, disk=name/alias)
> > > Example (dc=name, disk=name/alias)
> > > Example (sd=name, disk=name/alias)
> > 
> > it's not about accepting both name/alias, it's about missing
> > ability
> > to identify your resource in collection.
> > 
> > > For floating/shared on the same SD/DC/VM I would suggest a
> > > warning
> > > if there is a duplicate in the system - not enforcement.
> > 
> > ok, lets assume we WARN user that his disk's name is not unique,
> > how
> > user will pick the unique name?
> > implementing own code checking if new name (he wants to use) is
> > unique or not?
> > 
> > - this is business logic, not user's prerogative.
> > 
> > > There is a difference between best practice and being enforcing
> > > up
> > > to the level that it annoys some of the users.
> > 
> > simon, when you register to email, you have to try N times till you
> > find unique username,
> > is it convenient? absolutely NO, is it annoying? YES, but you
> > forced
> > doing that so
> > system will be able to identify you,
> > 
> > it's no different in any way, good software protects user/itself
> > even
> > in cost of convenience,
> > 
> > bottom line
> > ===========
> > 
> > - i think as long as disk not shared/floating it can have any name
> > - in a minute disk designation changed to shared, name uniqueness
> > should be forced (by the engine)
> > - when importing vm with shared disks, name uniqueness should be
> > forced
> > - when creating vm from template with shared disk, name uniqueness
> > should be forced
> > - alias should be changed back to name (in sake of consistency)
> > - /api/disks collection should support searching disks by name (in
> > sake of consistency)
> > 
> > 
> > thoughts?
> 
> Please look at the previous comment, that just can't work in the
> multi-tenancy case.
> Name should not be unique, the warning is for the admin only, from
> the user portal a warning should be issues only if the user provides
> same name twice.
> 
> 
> > 
> > > 
> > >>
> > >>
> > >> --
> > >>
> > >> Michael Pasternak
> > >> RedHat, ENG-Virtualization R&D
> > >> _______________________________________________
> > >> Engine-devel mailing list
> > >> Engine-devel at ovirt.org
> > >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> > >>
> > 
> > 
> > --
> > 
> > Michael Pasternak
> > RedHat, ENG-Virtualization R&D
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> 


From alonbl at redhat.com  Tue Oct 23 09:13:18 2012
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Tue, 23 Oct 2012 05:13:18 -0400 (EDT)
Subject: [Engine-devel] Splitting out the oVirt engine installer
In-Reply-To: <505F80F0.9010007@redhat.com>
Message-ID: <239053036.5048520.1350983598957.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Derek Higgins" <derekh at redhat.com>
> To: engine-devel at ovirt.org
> Sent: Sunday, September 23, 2012 11:36:48 PM
> Subject: [Engine-devel] Splitting out the oVirt engine installer
> 
> Hi All,
>     First time poster here so let me know if this is better directed
> some where else
> 
>     I have been writing a installer for openstack and as a base for
>     this
> I've split out the generic parts of your engine-setup utility[1].
> In order to do this I've created a generic installer[2] that is
> basically all of the parts of the oVirt engine installer that I
> needed
> for my openstack installer[3]
> 
> I'd now like to see if there is interest here to use this generic
> installer for oVirt.
> 
> I may have stripped out some stuff from the installer that I should
> have
> left in, if that is the case I'm open to recreating this repository
> with
> anything generic I shouldn't have stripped out so that the original
> history is maintained. Would anybody here like to look into the work
> necessary to use this installer in oVirt? For openstack I've made
> exclusive use of the plugin functionality and I suspect most changes
> that would be needed for oVirt would be to move a lot of the code
> into a
> similar pattern.
> 
> If you have any questions/comments just let me know, hopefully you
> will
> find this useful and other projects could make use of the great work
> you
> have done developing this setup utility
> 
> Thanks,
> Derek.
> 
> [1]
> https://github.com/derekhiggins/ovirt-engine/tree/master/packaging/fedora/setup
> [2] https://github.com/derekhiggins/installer
> [3] https://github.com/derekhiggins/os-installer

Hello Derek,

I re-wrote the vdsm-bootstrap, it was very complex and contained much legacy.

It turned out that the vdsm-bootstrap and the engine-setup/engine-upgrade has a lot in common.

So it is actually a base to any installer.

In short:
---
It is fully plugin, task oriented implementation.
Compatible with python-2.6, python-2.7, python-3.2
Fully localized enabled.
Single session interaction, no file transfer.
Local and remote execution modes are supported.
Distribution independent implementation (core).
---

The mission is to make it easy as much as possible to add new functionality without the complexity of the state and transaction management. If you look at the plugins directories, you will find the business logic, which is about 98% pure.

At the core of the implementation there is environment dictionary and a flow of stages within plugins. The environment can be modified using command-line parameters, configuration file, or dialog customization.

At the bottom of this message there is a sample of the dialog between manager and installer.

Although not 100% complete, I will be happy to receive any comment, suggestion and rejections.

A snapshot of development sources are available at[1].

I will be happy to receive your feedback!

Best Regards,
Alon Bar-Lev.

[1] https://github.com/alonbl/ovirt-installer


From dfediuck at redhat.com  Tue Oct 23 09:53:20 2012
From: dfediuck at redhat.com (Doron Fediuck)
Date: Tue, 23 Oct 2012 05:53:20 -0400 (EDT)
Subject: [Engine-devel] [vdsm] unmanaged devices thrown into 'custom'
 feature
In-Reply-To: <5084E7C0.8050504@redhat.com>
Message-ID: <1590967065.16069320.1350986000136.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Livnat Peer" <lpeer at redhat.com>
> To: "Dan Kenigsberg" <danken at redhat.com>
> Cc: engine-devel at ovirt.org, "Genadi Chereshnya" <gcheresh at redhat.com>, vdsm-devel at fedorahosted.org
> Sent: Monday, October 22, 2012 8:29:20 AM
> Subject: Re: [Engine-devel] [vdsm] unmanaged devices thrown into 'custom' feature
> 
> On 21/10/12 23:49, Dan Kenigsberg wrote:
> > On Sun, Oct 21, 2012 at 11:57:10AM -0400, Eli Mesika wrote:
> >>
> >>
> >> ----- Original Message -----
> >>> From: "Yair Zaslavsky" <yzaslavs at redhat.com>
> >>> To: "Livnat Peer" <lpeer at redhat.com>
> >>> Cc: "Genadi Chereshnya" <gcheresh at redhat.com>,
> >>> engine-devel at ovirt.org, vdsm-devel at fedorahosted.org
> >>> Sent: Sunday, October 21, 2012 5:38:54 PM
> >>> Subject: Re: [Engine-devel] unmanaged devices thrown into
> >>> 'custom' feature
> >>>
> >>>
> >>>
> >>> ----- Original Message -----
> >>>> From: "Livnat Peer" <lpeer at redhat.com>
> >>>> To: "Dan Kenigsberg" <danken at redhat.com>
> >>>> Cc: "Genadi Chereshnya" <gcheresh at redhat.com>,
> >>>> engine-devel at ovirt.org, vdsm-devel at fedorahosted.org
> >>>> Sent: Sunday, October 21, 2012 5:18:31 PM
> >>>> Subject: Re: [Engine-devel] unmanaged devices thrown into
> >>>> 'custom'
> >>>> feature
> >>>>
> >>>> On 21/10/12 16:42, Dan Kenigsberg wrote:
> >>>>> I have just noticed that when a VM is started for the second
> >>>>> time,
> >>>>> Engine
> >>>>> issues the "create" vdsm verb with some information regarding
> >>>>> "unmanaged" devices (an example is shown below[1]) in the
> >>>>> 'custom'
> >>>>> propery bag.
> >>>>>
> >>>>> I'm surprised about this, as I was not aware of this usage of
> >>>>> the
> >>>>> 'custom' dictionary, and Vdsm is not doing anything with the
> >>>>> data.
> >>>>>
> >>>>
> >>>> If I recall correctly the idea of passing the unmanaged devices
> >>>> data
> >>>> in
> >>>> the custom property was to enable managing stable device
> >>>> addresses
> >>>> in
> >>>> the hooks (to devices that were added to the VM via hooks from
> >>>> the
> >>>> first
> >>>> place), so this info is there not for VDSM use.
> >>>> For example if you add a device in a hook it will be kept in the
> >>>> engine
> >>>> as a non managed device. later when starting the VM again you
> >>>> would
> >>>> like
> >>>> to assign the same device address to your device, and you can do
> >>>> so
> >>>> because you have access to the original address in the custom
> >>>> properties
> >>>> of the VM.
> >>>
> >>> This is exactly what Eli has explained Gendai and Dan today.
> > 
> > (I was asking here because I did not understand the verbal
> > explanation.)
> > 
> >>
> >> This is taken from the Stable Device Address design in
> >> http://wiki.ovirt.org/wiki/Features/Design/StableDeviceAddresses
> >>
> >> Unmanaged Device
> >> -----------------
> >> Unmanaged Device will be supported in the new format and will
> >> include all unhandled devices as sound/controller/etc and future
> >> devices. Those devices will be persistent and will have Type ,
> >> SubType (device specific) and an Address. For 3.1 an unmanaged
> >> Device is not exposed to any GUI/REST API. Unmanaged devices are
> >> passed to vdsm inside a Custom property. VDSM in it turn is
> >> passing this as is for possible hook processing.
> > 
> > Thanks for the elaboration. Too bad that I've missed this issue
> > before.
> > 
> > Are you aware of any hook making use of this?  I hope that hook
> > writers
> > are not using APIs that are not documented in vdsmd(8).
> > 
> > It seems as a classic case where a generic bag interface is coerced
> > into
> > an awkward partially-documented interface.
> > 
> > I think that a better approach would have been to pass all devices
> > (managed and unmanaged alike) in the 'devices' property, and let
> > vdsm
> > expose whatever is needed to the before_vm_start hook.
> > 
> > Maybe we can still do this.
> 
> That was the original idea but Ayal objected and I think Igor did not
> like it as well...
> 

+2.
The original design had an 'unmanaged' (or generic) device type, and all
devices should have been normalized. But as explained, this was strongly
rejected in the VDSM side, causing Eli write some special handling for this anomaly.

> 
> > 
> > Dan.
> > _______________________________________________
> > vdsm-devel mailing list
> > vdsm-devel at lists.fedorahosted.org
> > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
> > 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From ewoud+ovirt at kohlvanwijngaarden.nl  Tue Oct 23 10:19:09 2012
From: ewoud+ovirt at kohlvanwijngaarden.nl (Ewoud Kohl van Wijngaarden)
Date: Tue, 23 Oct 2012 12:19:09 +0200
Subject: [Engine-devel] alias in disk instead of name
In-Reply-To: <1592047120.4617768.1350981413665.JavaMail.root@redhat.com>
References: <837208046.3632243.1350895802861.JavaMail.root@redhat.com>
	<1592047120.4617768.1350981413665.JavaMail.root@redhat.com>
Message-ID: <20121023101909.GN2094@bogey.xentower.nl>

On Tue, Oct 23, 2012 at 04:36:53AM -0400, Simon Grinberg wrote:
> We need more thoughts here from others, there are two different
> approaches on the table and more opinions are welcomed.
> If there are API consumers on this list then your view is more then
> welcomed.
As someone who has used the API for a multi tenancy situation I *know*
that the unique VM name contraint is very limiting. We ended up
restorting to giving all VMs a vmSOMEHASH name and storing the actual
names our customers wanted in the description field. This meant trading
in the ability to search for VM names but gave us the freedom we needed.

Now I haven't used the API with disks but I know our users generally
don't care about the names their drives have. However, I realise that
when you have detached disks they should be recognizable but can't you
enforce that when they're being detached? And with shared disks it might
be sufficient to show 'shared with VM X, Y and Z'.


From danken at redhat.com  Tue Oct 23 11:41:03 2012
From: danken at redhat.com (Dan Kenigsberg)
Date: Tue, 23 Oct 2012 13:41:03 +0200
Subject: [Engine-devel] [vdsm] unmanaged devices thrown into 'custom'
 feature
In-Reply-To: <1590967065.16069320.1350986000136.JavaMail.root@redhat.com>
References: <5084E7C0.8050504@redhat.com>
	<1590967065.16069320.1350986000136.JavaMail.root@redhat.com>
Message-ID: <20121023114103.GP17071@redhat.com>

On Tue, Oct 23, 2012 at 05:53:20AM -0400, Doron Fediuck wrote:
> 
> 
> ----- Original Message -----
> > From: "Livnat Peer" <lpeer at redhat.com>
> > To: "Dan Kenigsberg" <danken at redhat.com>
> > Cc: engine-devel at ovirt.org, "Genadi Chereshnya" <gcheresh at redhat.com>, vdsm-devel at fedorahosted.org
> > Sent: Monday, October 22, 2012 8:29:20 AM
> > Subject: Re: [Engine-devel] [vdsm] unmanaged devices thrown into 'custom' feature
> > 
> > On 21/10/12 23:49, Dan Kenigsberg wrote:
> > > On Sun, Oct 21, 2012 at 11:57:10AM -0400, Eli Mesika wrote:
> > >>
> > >>
> > >> ----- Original Message -----
> > >>> From: "Yair Zaslavsky" <yzaslavs at redhat.com>
> > >>> To: "Livnat Peer" <lpeer at redhat.com>
> > >>> Cc: "Genadi Chereshnya" <gcheresh at redhat.com>,
> > >>> engine-devel at ovirt.org, vdsm-devel at fedorahosted.org
> > >>> Sent: Sunday, October 21, 2012 5:38:54 PM
> > >>> Subject: Re: [Engine-devel] unmanaged devices thrown into
> > >>> 'custom' feature
> > >>>
> > >>>
> > >>>
> > >>> ----- Original Message -----
> > >>>> From: "Livnat Peer" <lpeer at redhat.com>
> > >>>> To: "Dan Kenigsberg" <danken at redhat.com>
> > >>>> Cc: "Genadi Chereshnya" <gcheresh at redhat.com>,
> > >>>> engine-devel at ovirt.org, vdsm-devel at fedorahosted.org
> > >>>> Sent: Sunday, October 21, 2012 5:18:31 PM
> > >>>> Subject: Re: [Engine-devel] unmanaged devices thrown into
> > >>>> 'custom'
> > >>>> feature
> > >>>>
> > >>>> On 21/10/12 16:42, Dan Kenigsberg wrote:
> > >>>>> I have just noticed that when a VM is started for the second
> > >>>>> time,
> > >>>>> Engine
> > >>>>> issues the "create" vdsm verb with some information regarding
> > >>>>> "unmanaged" devices (an example is shown below[1]) in the
> > >>>>> 'custom'
> > >>>>> propery bag.
> > >>>>>
> > >>>>> I'm surprised about this, as I was not aware of this usage of
> > >>>>> the
> > >>>>> 'custom' dictionary, and Vdsm is not doing anything with the
> > >>>>> data.
> > >>>>>
> > >>>>
> > >>>> If I recall correctly the idea of passing the unmanaged devices
> > >>>> data
> > >>>> in
> > >>>> the custom property was to enable managing stable device
> > >>>> addresses
> > >>>> in
> > >>>> the hooks (to devices that were added to the VM via hooks from
> > >>>> the
> > >>>> first
> > >>>> place), so this info is there not for VDSM use.
> > >>>> For example if you add a device in a hook it will be kept in the
> > >>>> engine
> > >>>> as a non managed device. later when starting the VM again you
> > >>>> would
> > >>>> like
> > >>>> to assign the same device address to your device, and you can do
> > >>>> so
> > >>>> because you have access to the original address in the custom
> > >>>> properties
> > >>>> of the VM.
> > >>>
> > >>> This is exactly what Eli has explained Gendai and Dan today.
> > > 
> > > (I was asking here because I did not understand the verbal
> > > explanation.)
> > > 
> > >>
> > >> This is taken from the Stable Device Address design in
> > >> http://wiki.ovirt.org/wiki/Features/Design/StableDeviceAddresses
> > >>
> > >> Unmanaged Device
> > >> -----------------
> > >> Unmanaged Device will be supported in the new format and will
> > >> include all unhandled devices as sound/controller/etc and future
> > >> devices. Those devices will be persistent and will have Type ,
> > >> SubType (device specific) and an Address. For 3.1 an unmanaged
> > >> Device is not exposed to any GUI/REST API. Unmanaged devices are
> > >> passed to vdsm inside a Custom property. VDSM in it turn is
> > >> passing this as is for possible hook processing.
> > > 
> > > Thanks for the elaboration. Too bad that I've missed this issue
> > > before.
> > > 
> > > Are you aware of any hook making use of this?  I hope that hook
> > > writers
> > > are not using APIs that are not documented in vdsmd(8).
> > > 
> > > It seems as a classic case where a generic bag interface is coerced
> > > into
> > > an awkward partially-documented interface.
> > > 
> > > I think that a better approach would have been to pass all devices
> > > (managed and unmanaged alike) in the 'devices' property, and let
> > > vdsm
> > > expose whatever is needed to the before_vm_start hook.
> > > 
> > > Maybe we can still do this.
> > 
> > That was the original idea but Ayal objected and I think Igor did not
> > like it as well...
> > 
> 
> +2.
> The original design had an 'unmanaged' (or generic) device type, and all
> devices should have been normalized. But as explained, this was strongly
> rejected in the VDSM side, causing Eli write some special handling for this anomaly.

Can someone (Ayal?) explain the rejection on Vdsm side?
Hiding part of the API in the custom propery bag requires strong
reasoning indeed.

Dan.



From ilvovsky at redhat.com  Tue Oct 23 12:02:43 2012
From: ilvovsky at redhat.com (Igor Lvovsky)
Date: Tue, 23 Oct 2012 08:02:43 -0400 (EDT)
Subject: [Engine-devel] [vdsm] unmanaged devices thrown into 'custom'
 feature
In-Reply-To: <20121023114103.GP17071@redhat.com>
Message-ID: <1335311734.570327.1350993763524.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Dan Kenigsberg" <danken at redhat.com>
> To: "Doron Fediuck" <dfediuck at redhat.com>
> Cc: engine-devel at ovirt.org, vdsm-devel at fedorahosted.org, "Genadi Chereshnya" <gcheresh at redhat.com>
> Sent: Tuesday, October 23, 2012 1:41:03 PM
> Subject: Re: [Engine-devel] [vdsm] unmanaged devices thrown into 'custom' feature
> 
> On Tue, Oct 23, 2012 at 05:53:20AM -0400, Doron Fediuck wrote:
> > 
> > 
> > ----- Original Message -----
> > > From: "Livnat Peer" <lpeer at redhat.com>
> > > To: "Dan Kenigsberg" <danken at redhat.com>
> > > Cc: engine-devel at ovirt.org, "Genadi Chereshnya"
> > > <gcheresh at redhat.com>, vdsm-devel at fedorahosted.org
> > > Sent: Monday, October 22, 2012 8:29:20 AM
> > > Subject: Re: [Engine-devel] [vdsm] unmanaged devices thrown into
> > > 'custom' feature
> > > 
> > > On 21/10/12 23:49, Dan Kenigsberg wrote:
> > > > On Sun, Oct 21, 2012 at 11:57:10AM -0400, Eli Mesika wrote:
> > > >>
> > > >>
> > > >> ----- Original Message -----
> > > >>> From: "Yair Zaslavsky" <yzaslavs at redhat.com>
> > > >>> To: "Livnat Peer" <lpeer at redhat.com>
> > > >>> Cc: "Genadi Chereshnya" <gcheresh at redhat.com>,
> > > >>> engine-devel at ovirt.org, vdsm-devel at fedorahosted.org
> > > >>> Sent: Sunday, October 21, 2012 5:38:54 PM
> > > >>> Subject: Re: [Engine-devel] unmanaged devices thrown into
> > > >>> 'custom' feature
> > > >>>
> > > >>>
> > > >>>
> > > >>> ----- Original Message -----
> > > >>>> From: "Livnat Peer" <lpeer at redhat.com>
> > > >>>> To: "Dan Kenigsberg" <danken at redhat.com>
> > > >>>> Cc: "Genadi Chereshnya" <gcheresh at redhat.com>,
> > > >>>> engine-devel at ovirt.org, vdsm-devel at fedorahosted.org
> > > >>>> Sent: Sunday, October 21, 2012 5:18:31 PM
> > > >>>> Subject: Re: [Engine-devel] unmanaged devices thrown into
> > > >>>> 'custom'
> > > >>>> feature
> > > >>>>
> > > >>>> On 21/10/12 16:42, Dan Kenigsberg wrote:
> > > >>>>> I have just noticed that when a VM is started for the
> > > >>>>> second
> > > >>>>> time,
> > > >>>>> Engine
> > > >>>>> issues the "create" vdsm verb with some information
> > > >>>>> regarding
> > > >>>>> "unmanaged" devices (an example is shown below[1]) in the
> > > >>>>> 'custom'
> > > >>>>> propery bag.
> > > >>>>>
> > > >>>>> I'm surprised about this, as I was not aware of this usage
> > > >>>>> of
> > > >>>>> the
> > > >>>>> 'custom' dictionary, and Vdsm is not doing anything with
> > > >>>>> the
> > > >>>>> data.
> > > >>>>>
> > > >>>>
> > > >>>> If I recall correctly the idea of passing the unmanaged
> > > >>>> devices
> > > >>>> data
> > > >>>> in
> > > >>>> the custom property was to enable managing stable device
> > > >>>> addresses
> > > >>>> in
> > > >>>> the hooks (to devices that were added to the VM via hooks
> > > >>>> from
> > > >>>> the
> > > >>>> first
> > > >>>> place), so this info is there not for VDSM use.
> > > >>>> For example if you add a device in a hook it will be kept in
> > > >>>> the
> > > >>>> engine
> > > >>>> as a non managed device. later when starting the VM again
> > > >>>> you
> > > >>>> would
> > > >>>> like
> > > >>>> to assign the same device address to your device, and you
> > > >>>> can do
> > > >>>> so
> > > >>>> because you have access to the original address in the
> > > >>>> custom
> > > >>>> properties
> > > >>>> of the VM.
> > > >>>
> > > >>> This is exactly what Eli has explained Gendai and Dan today.
> > > > 
> > > > (I was asking here because I did not understand the verbal
> > > > explanation.)
> > > > 
> > > >>
> > > >> This is taken from the Stable Device Address design in
> > > >> http://wiki.ovirt.org/wiki/Features/Design/StableDeviceAddresses
> > > >>
> > > >> Unmanaged Device
> > > >> -----------------
> > > >> Unmanaged Device will be supported in the new format and will
> > > >> include all unhandled devices as sound/controller/etc and
> > > >> future
> > > >> devices. Those devices will be persistent and will have Type ,
> > > >> SubType (device specific) and an Address. For 3.1 an unmanaged
> > > >> Device is not exposed to any GUI/REST API. Unmanaged devices
> > > >> are
> > > >> passed to vdsm inside a Custom property. VDSM in it turn is
> > > >> passing this as is for possible hook processing.
> > > > 
> > > > Thanks for the elaboration. Too bad that I've missed this issue
> > > > before.
> > > > 
> > > > Are you aware of any hook making use of this?  I hope that hook
> > > > writers
> > > > are not using APIs that are not documented in vdsmd(8).
> > > > 
> > > > It seems as a classic case where a generic bag interface is
> > > > coerced
> > > > into
> > > > an awkward partially-documented interface.
> > > > 
> > > > I think that a better approach would have been to pass all
> > > > devices
> > > > (managed and unmanaged alike) in the 'devices' property, and
> > > > let
> > > > vdsm
> > > > expose whatever is needed to the before_vm_start hook.
> > > > 
> > > > Maybe we can still do this.
> > > 
> > > That was the original idea but Ayal objected and I think Igor did
> > > not
> > > like it as well...
> > > 
> > 
> > +2.
> > The original design had an 'unmanaged' (or generic) device type,
> > and all
> > devices should have been normalized. But as explained, this was
> > strongly
> > rejected in the VDSM side, causing Eli write some special handling
> > for this anomaly.
> 
> Can someone (Ayal?) explain the rejection on Vdsm side?
> Hiding part of the API in the custom propery bag requires strong
> reasoning indeed.
> 

I can't recall any rejection from my side

> Dan.
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From omasad at redhat.com  Tue Oct 23 15:41:27 2012
From: omasad at redhat.com (Ofri Masad)
Date: Tue, 23 Oct 2012 11:41:27 -0400 (EDT)
Subject: [Engine-devel] Quota in 3.2 - design
Message-ID: <308040382.5120718.1351006887047.JavaMail.root@redhat.com>

Hi,

The new design for quota in 3.2 is available here: http://wiki.ovirt.org/wiki/Features/Design/Quota-3.2
Most of the changes would be in the backend.

Feedbacks would be more than welcome. We are trying to make quota more inherent (more framework like) and easier to handle when you create a new command.
Other than the design described in the wiki, we thought of two other designs which would help us identify the commands which are dependent on quota:
 1. Using annotations -
          by this approach we would add an annotation to the command class
          telling us it's a quota consumer and a second annotation to the method returning
          the consumption parameters.
 2. Using just interfaces without the markings in VdcActionType (this is the current implementation) -
          in this case the implemented interfaces are inherited by extending commands.
          So if one inherits some command without handling the quota parameters - we get
          wrong quota consumption and even holes in the quota.

again, any feedbacks would be more than welcome.
Thanks ahead,
Ofri


From medievalist at gmail.com  Tue Oct 23 16:51:35 2012
From: medievalist at gmail.com (Charlie)
Date: Tue, 23 Oct 2012 12:51:35 -0400
Subject: [Engine-devel] alias in disk instead of name
In-Reply-To: <1592047120.4617768.1350981413665.JavaMail.root@redhat.com>
References: <837208046.3632243.1350895802861.JavaMail.root@redhat.com>
	<1592047120.4617768.1350981413665.JavaMail.root@redhat.com>
Message-ID: <CAJb3uA6b1qnh+qVHRfo_EFGtaf5qdJ46Hy1QAhFxey6pi4B0gw@mail.gmail.com>

OK, only because you asked...

Provide default unique names, so that users can just press enter if
names don't matter to them.  That way you obviate the entire argument;
people who need special naming can have it, and everybody else has a
single extra keypress or mouseclick at naming time, and searching
works well enough.

You can name the first one vmdrive0 and increment the numeric part
each time a new drive is created.  Iterating until an unused name is
found isn't so computationally expensive that anyone should weep,
especially if you store the last used number and do an incrementing
sanity check against it at naming time.

People expect names to have significance, and we like it when they
have both unique and non-unique parts.  It's part of our human
heritage.  Maybe whales and dolphins don't care.

--Charlie

On Tue, Oct 23, 2012 at 4:36 AM, Simon Grinberg <simon at redhat.com> wrote:
>
> We need more thoughts here from others, there are two different approaches on the table and more opinions are welcomed.
> If there are API consumers on this list then your view is more then welcomed.
>
> Thanks,
> Simon.
>
> ----- Original Message -----
>> From: "Simon Grinberg" <simon at redhat.com>
>> To: "Michael Pasternak" <mpastern at redhat.com>
>> Cc: "engine-devel" <engine-devel at ovirt.org>
>> Sent: Monday, October 22, 2012 10:50:02 AM
>> Subject: Re: [Engine-devel] alias in disk instead of name
>>
>>
>>
>> ----- Original Message -----
>> > From: "Michael Pasternak" <mpastern at redhat.com>
>> > To: "Simon Grinberg" <simon at redhat.com>
>> > Cc: "engine-devel" <engine-devel at ovirt.org>
>> > 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" <mpastern at redhat.com>
>> > >> To: "Simon Grinberg" <simon at redhat.com>
>> > >> Cc: "engine-devel" <engine-devel at ovirt.org>
>> > >> 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" <mpastern at redhat.com>
>> > >>>> To: "Simon Grinberg" <simon at redhat.com>
>> > >>>> Cc: "engine-devel" <engine-devel at ovirt.org>
>> > >>>> 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" <mpastern at redhat.com>
>> > >>>>>>> To: "engine-devel" <engine-devel at ovirt.org>
>> > >>>>>>> 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 talking about /search,
>> > search is available only at /api/disks (i.e shared disks,
>> > vm/template.disks is
>> > irrelevant to this discussion)
>>
>> Nope I do not, but I think that our perspectives differ.
>> You are looking at it as strictly design issue. You have a collection
>> of entities and you want a human readable search, thus you are
>> trying to force (rightfully) from your point of view a unique
>> alias/name for those.
>>
>> I taking the end user perspective, and user experience
>> 1. Majority of the disks have no meaning outside of a VM scope.
>> 2. There are fractions of the disks that are usually shared (this is
>> the nature of shared disks)
>> 3. There are fractions of floating, most of the floating will be a
>> transient state, while you are moving disks around.
>>
>> What I'm trying to say that forcing a user to provide a unique name
>> per disk is a huge bother.
>> And again in the multi tenancy case, you can't enforce a unique alias
>> in the system.
>>
>> What will you say to the user in the error message?
>> Sorry you can't use this alias since another user that is sharing the
>> system with you already provided that name? And yes we know you
>> can't see that other disk, and it you don't care about the other
>> user, but still you can't use your alias since this is how our
>> platform designed.
>>
>> The meaning is that you must allow a for a more sophisticated search.
>> Yes even in the context of the disks tab. Disks are not really stand
>> alone entities, and if we keep to strict conventions like - in any
>> collection an entity name must be unique, then you are making the
>> system hardly usable for many users.
>>
>> So a search in disks should include other 'properties' (and yes I
>> know those are not disk properties, but this is how a user will look
>> at it) like owner,quota,vm,storage domain, etc.
>>
>> To some up - what should be unique are UUIDs of an entities, and
>> infrastructure entities names (within the same scope) - all the rest
>> must not.
>>
>>
>> >
>> > >
>> > >>
>> > >>>
>> > >>>>
>> > >>>>> Would you change these on import/export?
>> > >>>>
>> > >>>> would you mind elaborating on this?
>> > >>>
>> > >>> Yes,
>> > >>>
>> > >>> You are already facing a problem when importing VMs that
>> > >>> already
>> > >>> have the same name, now you increasing the problem for disks
>> > >>> that
>> > >>> have the same alias. for same name we force clone if you want
>> > >>> to
>> > >>> import. Why for clone just because of a disk alias (this
>> > >>> implies
>> > >>> collapse snapshots ATM) or even bother the user with renaming
>> > >>> disks that he does not care about the name so he just gave disk
>> > >>> 1,
>> > >>> 2, 3 and so on?
>> > >>
>> > >> i see your point, but then we leave no option for the user to
>> > >> locate
>> > >> the disk,
>> > >> simply because he doesn't have unique identifier,
>> > >>
>> > >> just imagine user A creating disk and calling it X,
>> > >> then user B creating disk and calling it X, they on different
>> > >> domains etc., and now both want to use disk X,
>> > >>
>> > >> how they can figure out which one to pick?, by SD, by size?
>> > >> agree
>> > >> this is doesn't look well..., even more than that - someone may
>> > >> call
>> > >> this "bad design"...
>> > >
>> > > This is why the search should accept more then the name.
>> > > Example (vm=name, disk=name/alias)
>> > > Example (dc=name, disk=name/alias)
>> > > Example (sd=name, disk=name/alias)
>> >
>> > it's not about accepting both name/alias, it's about missing
>> > ability
>> > to identify your resource in collection.
>> >
>> > > For floating/shared on the same SD/DC/VM I would suggest a
>> > > warning
>> > > if there is a duplicate in the system - not enforcement.
>> >
>> > ok, lets assume we WARN user that his disk's name is not unique,
>> > how
>> > user will pick the unique name?
>> > implementing own code checking if new name (he wants to use) is
>> > unique or not?
>> >
>> > - this is business logic, not user's prerogative.
>> >
>> > > There is a difference between best practice and being enforcing
>> > > up
>> > > to the level that it annoys some of the users.
>> >
>> > simon, when you register to email, you have to try N times till you
>> > find unique username,
>> > is it convenient? absolutely NO, is it annoying? YES, but you
>> > forced
>> > doing that so
>> > system will be able to identify you,
>> >
>> > it's no different in any way, good software protects user/itself
>> > even
>> > in cost of convenience,
>> >
>> > bottom line
>> > ===========
>> >
>> > - i think as long as disk not shared/floating it can have any name
>> > - in a minute disk designation changed to shared, name uniqueness
>> > should be forced (by the engine)
>> > - when importing vm with shared disks, name uniqueness should be
>> > forced
>> > - when creating vm from template with shared disk, name uniqueness
>> > should be forced
>> > - alias should be changed back to name (in sake of consistency)
>> > - /api/disks collection should support searching disks by name (in
>> > sake of consistency)
>> >
>> >
>> > thoughts?
>>
>> Please look at the previous comment, that just can't work in the
>> multi-tenancy case.
>> Name should not be unique, the warning is for the admin only, from
>> the user portal a warning should be issues only if the user provides
>> same name twice.
>>
>>
>> >
>> > >
>> > >>
>> > >>
>> > >> --
>> > >>
>> > >> Michael Pasternak
>> > >> RedHat, ENG-Virtualization R&D
>> > >> _______________________________________________
>> > >> Engine-devel mailing list
>> > >> Engine-devel at ovirt.org
>> > >> http://lists.ovirt.org/mailman/listinfo/engine-devel
>> > >>
>> >
>> >
>> > --
>> >
>> > Michael Pasternak
>> > RedHat, ENG-Virtualization R&D
>> > _______________________________________________
>> > Engine-devel mailing list
>> > Engine-devel at ovirt.org
>> > http://lists.ovirt.org/mailman/listinfo/engine-devel
>> >
>>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel


From simon at redhat.com  Tue Oct 23 17:10:46 2012
From: simon at redhat.com (Simon Grinberg)
Date: Tue, 23 Oct 2012 13:10:46 -0400 (EDT)
Subject: [Engine-devel] alias in disk instead of name
In-Reply-To: <CAJb3uA6b1qnh+qVHRfo_EFGtaf5qdJ46Hy1QAhFxey6pi4B0gw@mail.gmail.com>
Message-ID: <1954430365.5183121.1351012246648.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Charlie" <medievalist at gmail.com>
> To: "Simon Grinberg" <simon at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Tuesday, October 23, 2012 6:51:35 PM
> Subject: Re: [Engine-devel] alias in disk instead of name
> 
> OK, only because you asked...
> 
> Provide default unique names, so that users can just press enter if
> names don't matter to them.  That way you obviate the entire
> argument;
> people who need special naming can have it, and everybody else has a
> single extra keypress or mouseclick at naming time, and searching
> works well enough.
> 
> You can name the first one vmdrive0 and increment the numeric part
> each time a new drive is created.  Iterating until an unused name is
> found isn't so computationally expensive that anyone should weep,
> especially if you store the last used number and do an incrementing
> sanity check against it at naming time.

Let's say the above solved all conflicts when coming to create a new disk, it does seems so.

Let's say that import/export if names conflict can be solved in a reasonable way - for example forcing (somehow and without bothering the user too much) a rename of the disk (How would you know if the conflicting name id auto-generated so can be replaced or user provided?, you'll have to resort to non-that-human-look-alike-name)

How does it solve the multi-tenancy use case?
I'm tenant A, setting up a quorum disk for my two VMs - so I call this disk simply quorum.
Now comes tenant B, he is also setting up a quorum disk, so he tries to call his disk quorum

But no,
He'll get a popup that this name is already taken - bad luck buddy.
Now he needs to guess the next available name? Would you build in algorithm to suggest alternatives?
Why should tenant B care in the first place that tenant A also wanted to call his disk 'quorum'?

Same with the VM name - but that is given for now, though I hope to convince it should change in the future.

What I'm trying to say here - infrastructure is for the admin - so you can force uniqueness
Resources like, disks and Virtual Machine belong to the end user thus you should let them determine their own names without being restricted by users of the system.


      
> 
> People expect names to have significance, and we like it when they
> have both unique and non-unique parts.  It's part of our human
> heritage.  Maybe whales and dolphins don't care.



> 
> --Charlie
> 
> On Tue, Oct 23, 2012 at 4:36 AM, Simon Grinberg <simon at redhat.com>
> wrote:
> >
> > We need more thoughts here from others, there are two different
> > approaches on the table and more opinions are welcomed.
> > If there are API consumers on this list then your view is more then
> > welcomed.
> >
> > Thanks,
> > Simon.
> >
> > ----- Original Message -----
> >> From: "Simon Grinberg" <simon at redhat.com>
> >> To: "Michael Pasternak" <mpastern at redhat.com>
> >> Cc: "engine-devel" <engine-devel at ovirt.org>
> >> Sent: Monday, October 22, 2012 10:50:02 AM
> >> Subject: Re: [Engine-devel] alias in disk instead of name
> >>
> >>
> >>
> >> ----- Original Message -----
> >> > From: "Michael Pasternak" <mpastern at redhat.com>
> >> > To: "Simon Grinberg" <simon at redhat.com>
> >> > Cc: "engine-devel" <engine-devel at ovirt.org>
> >> > 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" <mpastern at redhat.com>
> >> > >> To: "Simon Grinberg" <simon at redhat.com>
> >> > >> Cc: "engine-devel" <engine-devel at ovirt.org>
> >> > >> 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" <mpastern at redhat.com>
> >> > >>>> To: "Simon Grinberg" <simon at redhat.com>
> >> > >>>> Cc: "engine-devel" <engine-devel at ovirt.org>
> >> > >>>> 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" <mpastern at redhat.com>
> >> > >>>>>>> To: "engine-devel" <engine-devel at ovirt.org>
> >> > >>>>>>> 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 talking about /search,
> >> > search is available only at /api/disks (i.e shared disks,
> >> > vm/template.disks is
> >> > irrelevant to this discussion)
> >>
> >> Nope I do not, but I think that our perspectives differ.
> >> You are looking at it as strictly design issue. You have a
> >> collection
> >> of entities and you want a human readable search, thus you are
> >> trying to force (rightfully) from your point of view a unique
> >> alias/name for those.
> >>
> >> I taking the end user perspective, and user experience
> >> 1. Majority of the disks have no meaning outside of a VM scope.
> >> 2. There are fractions of the disks that are usually shared (this
> >> is
> >> the nature of shared disks)
> >> 3. There are fractions of floating, most of the floating will be a
> >> transient state, while you are moving disks around.
> >>
> >> What I'm trying to say that forcing a user to provide a unique
> >> name
> >> per disk is a huge bother.
> >> And again in the multi tenancy case, you can't enforce a unique
> >> alias
> >> in the system.
> >>
> >> What will you say to the user in the error message?
> >> Sorry you can't use this alias since another user that is sharing
> >> the
> >> system with you already provided that name? And yes we know you
> >> can't see that other disk, and it you don't care about the other
> >> user, but still you can't use your alias since this is how our
> >> platform designed.
> >>
> >> The meaning is that you must allow a for a more sophisticated
> >> search.
> >> Yes even in the context of the disks tab. Disks are not really
> >> stand
> >> alone entities, and if we keep to strict conventions like - in any
> >> collection an entity name must be unique, then you are making the
> >> system hardly usable for many users.
> >>
> >> So a search in disks should include other 'properties' (and yes I
> >> know those are not disk properties, but this is how a user will
> >> look
> >> at it) like owner,quota,vm,storage domain, etc.
> >>
> >> To some up - what should be unique are UUIDs of an entities, and
> >> infrastructure entities names (within the same scope) - all the
> >> rest
> >> must not.
> >>
> >>
> >> >
> >> > >
> >> > >>
> >> > >>>
> >> > >>>>
> >> > >>>>> Would you change these on import/export?
> >> > >>>>
> >> > >>>> would you mind elaborating on this?
> >> > >>>
> >> > >>> Yes,
> >> > >>>
> >> > >>> You are already facing a problem when importing VMs that
> >> > >>> already
> >> > >>> have the same name, now you increasing the problem for disks
> >> > >>> that
> >> > >>> have the same alias. for same name we force clone if you
> >> > >>> want
> >> > >>> to
> >> > >>> import. Why for clone just because of a disk alias (this
> >> > >>> implies
> >> > >>> collapse snapshots ATM) or even bother the user with
> >> > >>> renaming
> >> > >>> disks that he does not care about the name so he just gave
> >> > >>> disk
> >> > >>> 1,
> >> > >>> 2, 3 and so on?
> >> > >>
> >> > >> i see your point, but then we leave no option for the user to
> >> > >> locate
> >> > >> the disk,
> >> > >> simply because he doesn't have unique identifier,
> >> > >>
> >> > >> just imagine user A creating disk and calling it X,
> >> > >> then user B creating disk and calling it X, they on different
> >> > >> domains etc., and now both want to use disk X,
> >> > >>
> >> > >> how they can figure out which one to pick?, by SD, by size?
> >> > >> agree
> >> > >> this is doesn't look well..., even more than that - someone
> >> > >> may
> >> > >> call
> >> > >> this "bad design"...
> >> > >
> >> > > This is why the search should accept more then the name.
> >> > > Example (vm=name, disk=name/alias)
> >> > > Example (dc=name, disk=name/alias)
> >> > > Example (sd=name, disk=name/alias)
> >> >
> >> > it's not about accepting both name/alias, it's about missing
> >> > ability
> >> > to identify your resource in collection.
> >> >
> >> > > For floating/shared on the same SD/DC/VM I would suggest a
> >> > > warning
> >> > > if there is a duplicate in the system - not enforcement.
> >> >
> >> > ok, lets assume we WARN user that his disk's name is not unique,
> >> > how
> >> > user will pick the unique name?
> >> > implementing own code checking if new name (he wants to use) is
> >> > unique or not?
> >> >
> >> > - this is business logic, not user's prerogative.
> >> >
> >> > > There is a difference between best practice and being
> >> > > enforcing
> >> > > up
> >> > > to the level that it annoys some of the users.
> >> >
> >> > simon, when you register to email, you have to try N times till
> >> > you
> >> > find unique username,
> >> > is it convenient? absolutely NO, is it annoying? YES, but you
> >> > forced
> >> > doing that so
> >> > system will be able to identify you,
> >> >
> >> > it's no different in any way, good software protects user/itself
> >> > even
> >> > in cost of convenience,
> >> >
> >> > bottom line
> >> > ===========
> >> >
> >> > - i think as long as disk not shared/floating it can have any
> >> > name
> >> > - in a minute disk designation changed to shared, name
> >> > uniqueness
> >> > should be forced (by the engine)
> >> > - when importing vm with shared disks, name uniqueness should be
> >> > forced
> >> > - when creating vm from template with shared disk, name
> >> > uniqueness
> >> > should be forced
> >> > - alias should be changed back to name (in sake of consistency)
> >> > - /api/disks collection should support searching disks by name
> >> > (in
> >> > sake of consistency)
> >> >
> >> >
> >> > thoughts?
> >>
> >> Please look at the previous comment, that just can't work in the
> >> multi-tenancy case.
> >> Name should not be unique, the warning is for the admin only, from
> >> the user portal a warning should be issues only if the user
> >> provides
> >> same name twice.
> >>
> >>
> >> >
> >> > >
> >> > >>
> >> > >>
> >> > >> --
> >> > >>
> >> > >> Michael Pasternak
> >> > >> RedHat, ENG-Virtualization R&D
> >> > >> _______________________________________________
> >> > >> Engine-devel mailing list
> >> > >> Engine-devel at ovirt.org
> >> > >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >> > >>
> >> >
> >> >
> >> > --
> >> >
> >> > Michael Pasternak
> >> > RedHat, ENG-Virtualization R&D
> >> > _______________________________________________
> >> > Engine-devel mailing list
> >> > Engine-devel at ovirt.org
> >> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >> >
> >>
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From vszocs at redhat.com  Tue Oct 23 17:35:11 2012
From: vszocs at redhat.com (Vojtech Szocs)
Date: Tue, 23 Oct 2012 13:35:11 -0400 (EDT)
Subject: [Engine-devel] UI Plugins: PoC patch revision 6 now available
In-Reply-To: <D290AD8432118048947689BA3AE8A9B3EA0073@SACEXCMBX04-PRD.hq.netapp.com>
Message-ID: <392790588.11440655.1351013711839.JavaMail.root@redhat.com>

Hi Chris, 

well, I planned to implement simple "show dialog with content loaded from given URL" plugin API function some time ago, but then I thought you might be experimenting with it already :) please feel free to work on that, we can include it into PoC revision 7. 

Regarding planned items for revision 7, here's my current list (feel free to add/modify things here if necessary): 

    * "add custom sub tab" plugin API function, with initial sub tab implementation showing content of the given URL (we can add more tab types later on, e.g. form-based or table-based tab) 
    * "add custom task to task pane" plugin API function, requires some UiCommon integration coding (I will handle this) 
    * "show dialog with content loaded from given URL" plugin API function, initial implementation could simply open new browser popup window using window.open (but any other approach is fine as well) 
    * integration with REST API, e.g. "obtain REST API authentication token" plugin API function, maybe also some API for performing actual HTTP REST calls? 



As for the Engine REST API authentication token, need to learn more about it, as WebAdmin GUI currently uses GWT RPC instead of REST API when communicating with the backend. 



You also mentioned that "we can make calls from our server into the REST API" - I assume this will be used together with "custom content for tab/dialog" plugin API functionality? (Otherwise I'd say the UI Plugin itself could make REST API calls on its own..) 



Regards, 
Vojtech 


----- Original Message -----

From: "Christopher Morrissey" <Christopher.Morrissey at netapp.com> 
To: "Vojtech Szocs" <vszocs at redhat.com>, "engine-devel" <engine-devel at ovirt.org> 
Sent: Monday, October 22, 2012 5:25:53 PM 
Subject: RE: [Engine-devel] UI Plugins: PoC patch revision 6 now available 



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. 


-Chris 



From: engine-devel-bounces at ovirt.org [mailto:engine-devel-bounces at 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 <OVIRT_HOME>/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, but this isn't relevant in our case). 

In contrast with traditional class-based object-oriented languages, JavaScript supports OOP through prototype-based programming model ( https://developer.mozilla.org/en-US/docs/JavaScript/Introduction_to_Object-Oriented_JavaScript ). At the same time, JavaScript language is dynamically-typed and therefore doesn't support traditional concept of interface in OOP, it uses "duck typing" technique instead ( http://en.wikipedia.org/wiki/Duck_typing ). 

The simplest way to provide an object that "implements the given interface" in JavaScript is to use "duck typing" technique: providing an object that contains well-known functions. In UI plugin infrastructure, I call this concept "interface object", represented by org.ovirt.engine.ui.webadmin.plugin.jsni.JsInterfaceObject class. Unlike the traditional concept of interface abstract type in object-oriented languages, an "interface object" does not necessarily have to declare all functions of the given interface in order to "implement" such interface. In fact, an empty object can be used as a valid "interface object". Missing functions will be simply treated as empty (no-op) functions. Furthermore, an "interface object" can "implement" multiple interfaces by declaring functions of those interfaces (interface composition). 

Getting back to "addMainTabActionButton" API, here's a sample code that adds new button to "Host" main tab data grid, as part of UiInit event handler function: 

UiInit: function () { 
api. addMainTabActionButton ('Host', 'Single-Host Action', 

// Action button interface object 
// All functions receive currently selected item(s) as function arguments 
{ 

// Called when the user clicks the button 
onClick : function () { 
// Calling 'arguments[0]' is safe, because onClick() can be called 
// only when exactly one item is currently selected in the data grid 
window.alert('Selected host entity ID = ' + arguments[0].entityId); 
}, 

// Returning 'true' means the button is enabled (clickable) 
// Returning 'false' means the button is disabled (non-clickable) 
// Default value = 'true' 
isEnabled : function () { 
// Enable button only when exactly one item is selected 
return arguments.length == 1; 
}, 

// Returning 'true' means the button is visible 
// Returning 'false' means the button is hidden 
// Default value = 'true' 
isAccessible : function () { 
// Always show the button in the corresponding data grid 
return true ; 
} 

} 

); 
} 

As mentioned above, all functions of an interface object are optional. For functions expecting return value, default value is defined by UI plugin infrastructure. For example: 

    * onClick - no default value (no return value expected) 
    * isEnabled / isAccessible - default value "true" (boolean return value expected) 

Note: UI plugin infrastructure checks the actual return value type, and uses default value in case the function returned something of wrong (unexpected) type. 

In the example above, "currently selected item(s)" maps to JSON-like representations of business entities currently selected in the corresponding data grid. For now, the entity representation is quite simple and same for all entity types: 

{ entityId: "[BusinessEntityGuidAsString]" } 

In future, we will create specific JSON-like representations for specific business entities, in compliance with Engine REST API entity structure. 

For a more extensive example of using "addMainTabActionButton" API, please see the attached "addMainTabActionButton.html.example" file. 



2. Improved plugin API function: addMainTab 

The "addMainTab" API was improved to address following issues: 

    * "addMainTab" can now be called at any moment during UI plugin runtime, given that the plugin is allowed invoke plugin API functions (plugin is either INITIALIZING or IN_USE). Previously, "addMainTab" worked reliably only when called from within UiInit event handler function. Currently, it's possible to call "addMainTab" at any moment, e.g. from within some other event handler function (after UiInit has completed). 


    * "addMainTab" now retains "active" tab (highlighted tab GUI). "addMainTab" works by adding new tab component (GWTP presenter proxy) and refreshing main tab panel GUI by removing all related tabs and re-adding them again. This logic is handled by org.ovirt.engine.ui.common.presenter.DynamicTabContainerPresenter class, which makes sure that "active" tab is retained even after main tab panel was refreshed. 

Furthermore, custom main tab implementation now displays the content of the given URL through HTML iframe element. 



3. Improved native JavaScript function handling (GWT JSNI) 

This patch introduces org.ovirt.engine.ui.webadmin.plugin.jsni.JsFunction and org.ovirt.engine.ui.webadmin.plugin.jsni.JsFunctionResultHelper classes providing Java abstraction for invoking native JavaScript functions. These classes follow the general contract of "interface object" as mentioned above. 

JsFunctionResultHelper is particularly useful when dealing with functions which are expected to return value of a certain type. Too bad standard GWT JSNI classes don't provide such abstraction for working with native functions out-of-the-box... 



4. ActionPanel and ActionTable type hierarchy refactoring (related to "addMainTabActionButton" API) 

Previously, AbstractActionPanel and AbstractActionTable classes didn't implement any reasonable interface that would allow other components (client-side UI plugin infrastructure) to depend on their functionality in a loosely-coupled manner. This would make code that implements "addMainTabActionButton" API "ugly": main tab view interface would have to reference AbstractActionTable class directly. In MVP design pattern, view interface should avoid referencing specific GWT Widget classes directly. 

This patch introduces new interfaces for ActionPanel and ActionTable components while eliminating code redundancy (duplicate or unnecessary code). 



5. ActionPanel type hierarchy refactoring (related to "addMainTab" API) 

Since org.ovirt.engine.ui.common.presenter.DynamicTabContainerPresenter defines new DynamicTabPanel interface that extends standard GWTP TabPanel interface, some refactoring had to be done in related ActionPanel classes. 

This patch makes sure that both org.ovirt.engine.ui.common.widget.tab.AbstractTabPanel (widget) and org.ovirt.engine.ui.common.view.AbstractTabPanelView (view) support DynamicTabPanel interface. 

Note that for now, only main tab panel (org.ovirt.engine.ui.webadmin.section.main.presenter.MainTabPanelPresenter) supports dynamic tabs within its view. 



Where is addSubTab API function? 

Implementing "addSubTab" API requires some more changes, and I didn't want to delay this PoC patch just because of it... 

Here's a sample code that illustrates proposed "addSubTab" API usage: 

UiInit: function () { 
api. addSubTab ('Host', // entityTypeName 
'Custom Host Sub Tab', // label 
'custom-host-sub-tab', // historyToken 
'http://www.ovirt.org/', // contentUrl 

// Sub tab interface object 
// All functions receive currently selected item(s) 
// within the main tab data grid as function arguments 
{ 

// Returning 'true' means the sub tab is visible 
// Returning 'false' means the sub tab is hidden 
// Default value = 'true' 
isAccessible : function () { 
return arguments.length == 1 && arguments[0].entityId == '<MyHostEntityId>'; 
} 

} 

); 
} 

As part of "addSubTab" API implementation, I'll refactor custom main tab components, in order to use one "tab type" for both main and sub tabs. 

Currently, we have one (and only one) "tab type" - a tab that shows content of the given URL through HTML iframe element. 

We could also create new "tab types", e.g. form-based tab that shows key/value pairs (IMHO this could be quite useful for custom sub tabs). 



Let me know what you think! 

Cheers, 
Vojtech 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20121023/585bc9b3/attachment.html>

From medievalist at gmail.com  Tue Oct 23 17:53:10 2012
From: medievalist at gmail.com (Charlie)
Date: Tue, 23 Oct 2012 13:53:10 -0400
Subject: [Engine-devel] alias in disk instead of name
In-Reply-To: <1954430365.5183121.1351012246648.JavaMail.root@redhat.com>
References: <CAJb3uA6b1qnh+qVHRfo_EFGtaf5qdJ46Hy1QAhFxey6pi4B0gw@mail.gmail.com>
	<1954430365.5183121.1351012246648.JavaMail.root@redhat.com>
Message-ID: <CAJb3uA5Z8YOqaWhaPZVpKrwcUM2LzR+H8N8wYLu3Ao4OrsUKFw@mail.gmail.com>

Why not something like this?

(pseudocode, using dot for string concatenation):

$name_prefix = "vmdrive"
$name = get_last_used($name_prefix)
$already_in_use = $TRUE

while $already_in_use {
     prompt "Name of thing? [$name] ", $name
     if name_used($name) {
         while name_used($name) {
            increment_number($name)
         }
     } else {
         $already_in_use = FALSE
     }
}

do_whatever_you_do_with($name)

store_last_used($name)

end


The increment_number() routine checks to see if the last character is
numeric, and if it is, increments the leftmost contiguous numeric
portion of the string.  Otherwise it appends the number zero.

This does not allow everyone to get any name they want, but you can't
ever satisfy that demand.  It supplies reasonable defaults very
quickly and it allows people who want really descriptive names to try
as many as they like.

The code's built the funny way it is so that you can corrupt the db
that holds the last_used numbers or interrupt the process halfway
through and it still works, only slower, and it should tend to fix its
own db on the fly when possible.

There's no provision for simultaneous creation, but that wouldn't be
horribly hard to add, just put a lock on the resource holding
last_used numbers.

You'd want to reimplement in the most efficient and readable way for
your programming language of choice.

Did that make any sense?  I did it off the top of my head, so it could
be terribly lame when I look at it tomorrow ;).

--Charlie

On Tue, Oct 23, 2012 at 1:10 PM, Simon Grinberg <simon at redhat.com> wrote:
>
>
> ----- Original Message -----
>> From: "Charlie" <medievalist at gmail.com>
>> To: "Simon Grinberg" <simon at redhat.com>
>> Cc: "engine-devel" <engine-devel at ovirt.org>
>> Sent: Tuesday, October 23, 2012 6:51:35 PM
>> Subject: Re: [Engine-devel] alias in disk instead of name
>>
>> OK, only because you asked...
>>
>> Provide default unique names, so that users can just press enter if
>> names don't matter to them.  That way you obviate the entire
>> argument;
>> people who need special naming can have it, and everybody else has a
>> single extra keypress or mouseclick at naming time, and searching
>> works well enough.
>>
>> You can name the first one vmdrive0 and increment the numeric part
>> each time a new drive is created.  Iterating until an unused name is
>> found isn't so computationally expensive that anyone should weep,
>> especially if you store the last used number and do an incrementing
>> sanity check against it at naming time.
>
> Let's say the above solved all conflicts when coming to create a new disk, it does seems so.
>
> Let's say that import/export if names conflict can be solved in a reasonable way - for example forcing (somehow and without bothering the user too much) a rename of the disk (How would you know if the conflicting name id auto-generated so can be replaced or user provided?, you'll have to resort to non-that-human-look-alike-name)
>
> How does it solve the multi-tenancy use case?
> I'm tenant A, setting up a quorum disk for my two VMs - so I call this disk simply quorum.
> Now comes tenant B, he is also setting up a quorum disk, so he tries to call his disk quorum
>
> But no,
> He'll get a popup that this name is already taken - bad luck buddy.
> Now he needs to guess the next available name? Would you build in algorithm to suggest alternatives?
> Why should tenant B care in the first place that tenant A also wanted to call his disk 'quorum'?
>
> Same with the VM name - but that is given for now, though I hope to convince it should change in the future.
>
> What I'm trying to say here - infrastructure is for the admin - so you can force uniqueness
> Resources like, disks and Virtual Machine belong to the end user thus you should let them determine their own names without being restricted by users of the system.
>
>
>
>>
>> People expect names to have significance, and we like it when they
>> have both unique and non-unique parts.  It's part of our human
>> heritage.  Maybe whales and dolphins don't care.
>
>
>
>>
>> --Charlie
>>
>> On Tue, Oct 23, 2012 at 4:36 AM, Simon Grinberg <simon at redhat.com>
>> wrote:
>> >
>> > We need more thoughts here from others, there are two different
>> > approaches on the table and more opinions are welcomed.
>> > If there are API consumers on this list then your view is more then
>> > welcomed.
>> >
>> > Thanks,
>> > Simon.
>> >
>> > ----- Original Message -----
>> >> From: "Simon Grinberg" <simon at redhat.com>
>> >> To: "Michael Pasternak" <mpastern at redhat.com>
>> >> Cc: "engine-devel" <engine-devel at ovirt.org>
>> >> Sent: Monday, October 22, 2012 10:50:02 AM
>> >> Subject: Re: [Engine-devel] alias in disk instead of name
>> >>
>> >>
>> >>
>> >> ----- Original Message -----
>> >> > From: "Michael Pasternak" <mpastern at redhat.com>
>> >> > To: "Simon Grinberg" <simon at redhat.com>
>> >> > Cc: "engine-devel" <engine-devel at ovirt.org>
>> >> > 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" <mpastern at redhat.com>
>> >> > >> To: "Simon Grinberg" <simon at redhat.com>
>> >> > >> Cc: "engine-devel" <engine-devel at ovirt.org>
>> >> > >> 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" <mpastern at redhat.com>
>> >> > >>>> To: "Simon Grinberg" <simon at redhat.com>
>> >> > >>>> Cc: "engine-devel" <engine-devel at ovirt.org>
>> >> > >>>> 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" <mpastern at redhat.com>
>> >> > >>>>>>> To: "engine-devel" <engine-devel at ovirt.org>
>> >> > >>>>>>> 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 talking about /search,
>> >> > search is available only at /api/disks (i.e shared disks,
>> >> > vm/template.disks is
>> >> > irrelevant to this discussion)
>> >>
>> >> Nope I do not, but I think that our perspectives differ.
>> >> You are looking at it as strictly design issue. You have a
>> >> collection
>> >> of entities and you want a human readable search, thus you are
>> >> trying to force (rightfully) from your point of view a unique
>> >> alias/name for those.
>> >>
>> >> I taking the end user perspective, and user experience
>> >> 1. Majority of the disks have no meaning outside of a VM scope.
>> >> 2. There are fractions of the disks that are usually shared (this
>> >> is
>> >> the nature of shared disks)
>> >> 3. There are fractions of floating, most of the floating will be a
>> >> transient state, while you are moving disks around.
>> >>
>> >> What I'm trying to say that forcing a user to provide a unique
>> >> name
>> >> per disk is a huge bother.
>> >> And again in the multi tenancy case, you can't enforce a unique
>> >> alias
>> >> in the system.
>> >>
>> >> What will you say to the user in the error message?
>> >> Sorry you can't use this alias since another user that is sharing
>> >> the
>> >> system with you already provided that name? And yes we know you
>> >> can't see that other disk, and it you don't care about the other
>> >> user, but still you can't use your alias since this is how our
>> >> platform designed.
>> >>
>> >> The meaning is that you must allow a for a more sophisticated
>> >> search.
>> >> Yes even in the context of the disks tab. Disks are not really
>> >> stand
>> >> alone entities, and if we keep to strict conventions like - in any
>> >> collection an entity name must be unique, then you are making the
>> >> system hardly usable for many users.
>> >>
>> >> So a search in disks should include other 'properties' (and yes I
>> >> know those are not disk properties, but this is how a user will
>> >> look
>> >> at it) like owner,quota,vm,storage domain, etc.
>> >>
>> >> To some up - what should be unique are UUIDs of an entities, and
>> >> infrastructure entities names (within the same scope) - all the
>> >> rest
>> >> must not.
>> >>
>> >>
>> >> >
>> >> > >
>> >> > >>
>> >> > >>>
>> >> > >>>>
>> >> > >>>>> Would you change these on import/export?
>> >> > >>>>
>> >> > >>>> would you mind elaborating on this?
>> >> > >>>
>> >> > >>> Yes,
>> >> > >>>
>> >> > >>> You are already facing a problem when importing VMs that
>> >> > >>> already
>> >> > >>> have the same name, now you increasing the problem for disks
>> >> > >>> that
>> >> > >>> have the same alias. for same name we force clone if you
>> >> > >>> want
>> >> > >>> to
>> >> > >>> import. Why for clone just because of a disk alias (this
>> >> > >>> implies
>> >> > >>> collapse snapshots ATM) or even bother the user with
>> >> > >>> renaming
>> >> > >>> disks that he does not care about the name so he just gave
>> >> > >>> disk
>> >> > >>> 1,
>> >> > >>> 2, 3 and so on?
>> >> > >>
>> >> > >> i see your point, but then we leave no option for the user to
>> >> > >> locate
>> >> > >> the disk,
>> >> > >> simply because he doesn't have unique identifier,
>> >> > >>
>> >> > >> just imagine user A creating disk and calling it X,
>> >> > >> then user B creating disk and calling it X, they on different
>> >> > >> domains etc., and now both want to use disk X,
>> >> > >>
>> >> > >> how they can figure out which one to pick?, by SD, by size?
>> >> > >> agree
>> >> > >> this is doesn't look well..., even more than that - someone
>> >> > >> may
>> >> > >> call
>> >> > >> this "bad design"...
>> >> > >
>> >> > > This is why the search should accept more then the name.
>> >> > > Example (vm=name, disk=name/alias)
>> >> > > Example (dc=name, disk=name/alias)
>> >> > > Example (sd=name, disk=name/alias)
>> >> >
>> >> > it's not about accepting both name/alias, it's about missing
>> >> > ability
>> >> > to identify your resource in collection.
>> >> >
>> >> > > For floating/shared on the same SD/DC/VM I would suggest a
>> >> > > warning
>> >> > > if there is a duplicate in the system - not enforcement.
>> >> >
>> >> > ok, lets assume we WARN user that his disk's name is not unique,
>> >> > how
>> >> > user will pick the unique name?
>> >> > implementing own code checking if new name (he wants to use) is
>> >> > unique or not?
>> >> >
>> >> > - this is business logic, not user's prerogative.
>> >> >
>> >> > > There is a difference between best practice and being
>> >> > > enforcing
>> >> > > up
>> >> > > to the level that it annoys some of the users.
>> >> >
>> >> > simon, when you register to email, you have to try N times till
>> >> > you
>> >> > find unique username,
>> >> > is it convenient? absolutely NO, is it annoying? YES, but you
>> >> > forced
>> >> > doing that so
>> >> > system will be able to identify you,
>> >> >
>> >> > it's no different in any way, good software protects user/itself
>> >> > even
>> >> > in cost of convenience,
>> >> >
>> >> > bottom line
>> >> > ===========
>> >> >
>> >> > - i think as long as disk not shared/floating it can have any
>> >> > name
>> >> > - in a minute disk designation changed to shared, name
>> >> > uniqueness
>> >> > should be forced (by the engine)
>> >> > - when importing vm with shared disks, name uniqueness should be
>> >> > forced
>> >> > - when creating vm from template with shared disk, name
>> >> > uniqueness
>> >> > should be forced
>> >> > - alias should be changed back to name (in sake of consistency)
>> >> > - /api/disks collection should support searching disks by name
>> >> > (in
>> >> > sake of consistency)
>> >> >
>> >> >
>> >> > thoughts?
>> >>
>> >> Please look at the previous comment, that just can't work in the
>> >> multi-tenancy case.
>> >> Name should not be unique, the warning is for the admin only, from
>> >> the user portal a warning should be issues only if the user
>> >> provides
>> >> same name twice.
>> >>
>> >>
>> >> >
>> >> > >
>> >> > >>
>> >> > >>
>> >> > >> --
>> >> > >>
>> >> > >> Michael Pasternak
>> >> > >> RedHat, ENG-Virtualization R&D
>> >> > >> _______________________________________________
>> >> > >> Engine-devel mailing list
>> >> > >> Engine-devel at ovirt.org
>> >> > >> http://lists.ovirt.org/mailman/listinfo/engine-devel
>> >> > >>
>> >> >
>> >> >
>> >> > --
>> >> >
>> >> > Michael Pasternak
>> >> > RedHat, ENG-Virtualization R&D
>> >> > _______________________________________________
>> >> > Engine-devel mailing list
>> >> > Engine-devel at ovirt.org
>> >> > http://lists.ovirt.org/mailman/listinfo/engine-devel
>> >> >
>> >>
>> > _______________________________________________
>> > Engine-devel mailing list
>> > Engine-devel at ovirt.org
>> > http://lists.ovirt.org/mailman/listinfo/engine-devel
>>


From simon at redhat.com  Tue Oct 23 18:07:45 2012
From: simon at redhat.com (Simon Grinberg)
Date: Tue, 23 Oct 2012 14:07:45 -0400 (EDT)
Subject: [Engine-devel] alias in disk instead of name
In-Reply-To: <CAJb3uA5Z8YOqaWhaPZVpKrwcUM2LzR+H8N8wYLu3Ao4OrsUKFw@mail.gmail.com>
Message-ID: <1638221000.5207513.1351015665244.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Charlie" <medievalist at gmail.com>
> To: "Simon Grinberg" <simon at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Tuesday, October 23, 2012 7:53:10 PM
> Subject: Re: [Engine-devel] alias in disk instead of name
> 
> Why not something like this?
> 
> (pseudocode, using dot for string concatenation):
> 
> $name_prefix = "vmdrive"
> $name = get_last_used($name_prefix)
> $already_in_use = $TRUE
> 
> while $already_in_use {
>      prompt "Name of thing? [$name] ", $name
>      if name_used($name) {
>          while name_used($name) {
>             increment_number($name)
>          }
>      } else {
>          $already_in_use = FALSE
>      }
> }
> 
> do_whatever_you_do_with($name)
> 
> store_last_used($name)
> 
> end
> 
> 
> The increment_number() routine checks to see if the last character is
> numeric, and if it is, increments the leftmost contiguous numeric
> portion of the string.  Otherwise it appends the number zero.
> 
> This does not allow everyone to get any name they want, but you can't
> ever satisfy that demand.  It supplies reasonable defaults very
> quickly and it allows people who want really descriptive names to try
> as many as they like.
> 
> The code's built the funny way it is so that you can corrupt the db
> that holds the last_used numbers or interrupt the process halfway
> through and it still works, only slower, and it should tend to fix
> its
> own db on the fly when possible.
> 
> There's no provision for simultaneous creation, but that wouldn't be
> horribly hard to add, just put a lock on the resource holding
> last_used numbers.
> 
> You'd want to reimplement in the most efficient and readable way for
> your programming language of choice.
> 
> Did that make any sense?  I did it off the top of my head, so it
> could
> be terribly lame when I look at it tomorrow ;).

Please don't look at it as pure programming item, nor as a single user in a small data center - in this respect you are right.
Let's got to a huge organization or to the cloud.

In multi tenant environment this lock means that every time a user tries to change a disk name - all the others are stack
Don't forget we are discussing thousands of VMs - I'll hate to have this kind of lock just to allow for unique disk names. This is one of the reasons you use UUID to really identify the object in the DB, since it's suppose to guarantee uniqueness without the need to lock everything.

And again - please look at this as an end user, why do I care that other users had decided they are going to use the same name as me? This is my human readable name and I want to choose what ever I like without considering other users. What is this self service portal worth if I can't name my VMs and Disks as I'd like to, oblivious to others?

At the end of day, you want oVirt to be useful and scalable - and not just code wise correct.  


> 
> --Charlie
> 
> On Tue, Oct 23, 2012 at 1:10 PM, Simon Grinberg <simon at redhat.com>
> wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Charlie" <medievalist at gmail.com>
> >> To: "Simon Grinberg" <simon at redhat.com>
> >> Cc: "engine-devel" <engine-devel at ovirt.org>
> >> Sent: Tuesday, October 23, 2012 6:51:35 PM
> >> Subject: Re: [Engine-devel] alias in disk instead of name
> >>
> >> OK, only because you asked...
> >>
> >> Provide default unique names, so that users can just press enter
> >> if
> >> names don't matter to them.  That way you obviate the entire
> >> argument;
> >> people who need special naming can have it, and everybody else has
> >> a
> >> single extra keypress or mouseclick at naming time, and searching
> >> works well enough.
> >>
> >> You can name the first one vmdrive0 and increment the numeric part
> >> each time a new drive is created.  Iterating until an unused name
> >> is
> >> found isn't so computationally expensive that anyone should weep,
> >> especially if you store the last used number and do an
> >> incrementing
> >> sanity check against it at naming time.
> >
> > Let's say the above solved all conflicts when coming to create a
> > new disk, it does seems so.
> >
> > Let's say that import/export if names conflict can be solved in a
> > reasonable way - for example forcing (somehow and without
> > bothering the user too much) a rename of the disk (How would you
> > know if the conflicting name id auto-generated so can be replaced
> > or user provided?, you'll have to resort to
> > non-that-human-look-alike-name)
> >
> > How does it solve the multi-tenancy use case?
> > I'm tenant A, setting up a quorum disk for my two VMs - so I call
> > this disk simply quorum.
> > Now comes tenant B, he is also setting up a quorum disk, so he
> > tries to call his disk quorum
> >
> > But no,
> > He'll get a popup that this name is already taken - bad luck buddy.
> > Now he needs to guess the next available name? Would you build in
> > algorithm to suggest alternatives?
> > Why should tenant B care in the first place that tenant A also
> > wanted to call his disk 'quorum'?
> >
> > Same with the VM name - but that is given for now, though I hope to
> > convince it should change in the future.
> >
> > What I'm trying to say here - infrastructure is for the admin - so
> > you can force uniqueness
> > Resources like, disks and Virtual Machine belong to the end user
> > thus you should let them determine their own names without being
> > restricted by users of the system.
> >
> >
> >
> >>
> >> People expect names to have significance, and we like it when they
> >> have both unique and non-unique parts.  It's part of our human
> >> heritage.  Maybe whales and dolphins don't care.
> >
> >
> >
> >>
> >> --Charlie
> >>
> >> On Tue, Oct 23, 2012 at 4:36 AM, Simon Grinberg <simon at redhat.com>
> >> wrote:
> >> >
> >> > We need more thoughts here from others, there are two different
> >> > approaches on the table and more opinions are welcomed.
> >> > If there are API consumers on this list then your view is more
> >> > then
> >> > welcomed.
> >> >
> >> > Thanks,
> >> > Simon.
> >> >
> >> > ----- Original Message -----
> >> >> From: "Simon Grinberg" <simon at redhat.com>
> >> >> To: "Michael Pasternak" <mpastern at redhat.com>
> >> >> Cc: "engine-devel" <engine-devel at ovirt.org>
> >> >> Sent: Monday, October 22, 2012 10:50:02 AM
> >> >> Subject: Re: [Engine-devel] alias in disk instead of name
> >> >>
> >> >>
> >> >>
> >> >> ----- Original Message -----
> >> >> > From: "Michael Pasternak" <mpastern at redhat.com>
> >> >> > To: "Simon Grinberg" <simon at redhat.com>
> >> >> > Cc: "engine-devel" <engine-devel at ovirt.org>
> >> >> > 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" <mpastern at redhat.com>
> >> >> > >> To: "Simon Grinberg" <simon at redhat.com>
> >> >> > >> Cc: "engine-devel" <engine-devel at ovirt.org>
> >> >> > >> 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" <mpastern at redhat.com>
> >> >> > >>>> To: "Simon Grinberg" <simon at redhat.com>
> >> >> > >>>> Cc: "engine-devel" <engine-devel at ovirt.org>
> >> >> > >>>> 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" <mpastern at redhat.com>
> >> >> > >>>>>>> To: "engine-devel" <engine-devel at ovirt.org>
> >> >> > >>>>>>> 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 talking about /search,
> >> >> > search is available only at /api/disks (i.e shared disks,
> >> >> > vm/template.disks is
> >> >> > irrelevant to this discussion)
> >> >>
> >> >> Nope I do not, but I think that our perspectives differ.
> >> >> You are looking at it as strictly design issue. You have a
> >> >> collection
> >> >> of entities and you want a human readable search, thus you are
> >> >> trying to force (rightfully) from your point of view a unique
> >> >> alias/name for those.
> >> >>
> >> >> I taking the end user perspective, and user experience
> >> >> 1. Majority of the disks have no meaning outside of a VM scope.
> >> >> 2. There are fractions of the disks that are usually shared
> >> >> (this
> >> >> is
> >> >> the nature of shared disks)
> >> >> 3. There are fractions of floating, most of the floating will
> >> >> be a
> >> >> transient state, while you are moving disks around.
> >> >>
> >> >> What I'm trying to say that forcing a user to provide a unique
> >> >> name
> >> >> per disk is a huge bother.
> >> >> And again in the multi tenancy case, you can't enforce a unique
> >> >> alias
> >> >> in the system.
> >> >>
> >> >> What will you say to the user in the error message?
> >> >> Sorry you can't use this alias since another user that is
> >> >> sharing
> >> >> the
> >> >> system with you already provided that name? And yes we know you
> >> >> can't see that other disk, and it you don't care about the
> >> >> other
> >> >> user, but still you can't use your alias since this is how our
> >> >> platform designed.
> >> >>
> >> >> The meaning is that you must allow a for a more sophisticated
> >> >> search.
> >> >> Yes even in the context of the disks tab. Disks are not really
> >> >> stand
> >> >> alone entities, and if we keep to strict conventions like - in
> >> >> any
> >> >> collection an entity name must be unique, then you are making
> >> >> the
> >> >> system hardly usable for many users.
> >> >>
> >> >> So a search in disks should include other 'properties' (and yes
> >> >> I
> >> >> know those are not disk properties, but this is how a user will
> >> >> look
> >> >> at it) like owner,quota,vm,storage domain, etc.
> >> >>
> >> >> To some up - what should be unique are UUIDs of an entities,
> >> >> and
> >> >> infrastructure entities names (within the same scope) - all the
> >> >> rest
> >> >> must not.
> >> >>
> >> >>
> >> >> >
> >> >> > >
> >> >> > >>
> >> >> > >>>
> >> >> > >>>>
> >> >> > >>>>> Would you change these on import/export?
> >> >> > >>>>
> >> >> > >>>> would you mind elaborating on this?
> >> >> > >>>
> >> >> > >>> Yes,
> >> >> > >>>
> >> >> > >>> You are already facing a problem when importing VMs that
> >> >> > >>> already
> >> >> > >>> have the same name, now you increasing the problem for
> >> >> > >>> disks
> >> >> > >>> that
> >> >> > >>> have the same alias. for same name we force clone if you
> >> >> > >>> want
> >> >> > >>> to
> >> >> > >>> import. Why for clone just because of a disk alias (this
> >> >> > >>> implies
> >> >> > >>> collapse snapshots ATM) or even bother the user with
> >> >> > >>> renaming
> >> >> > >>> disks that he does not care about the name so he just
> >> >> > >>> gave
> >> >> > >>> disk
> >> >> > >>> 1,
> >> >> > >>> 2, 3 and so on?
> >> >> > >>
> >> >> > >> i see your point, but then we leave no option for the user
> >> >> > >> to
> >> >> > >> locate
> >> >> > >> the disk,
> >> >> > >> simply because he doesn't have unique identifier,
> >> >> > >>
> >> >> > >> just imagine user A creating disk and calling it X,
> >> >> > >> then user B creating disk and calling it X, they on
> >> >> > >> different
> >> >> > >> domains etc., and now both want to use disk X,
> >> >> > >>
> >> >> > >> how they can figure out which one to pick?, by SD, by
> >> >> > >> size?
> >> >> > >> agree
> >> >> > >> this is doesn't look well..., even more than that -
> >> >> > >> someone
> >> >> > >> may
> >> >> > >> call
> >> >> > >> this "bad design"...
> >> >> > >
> >> >> > > This is why the search should accept more then the name.
> >> >> > > Example (vm=name, disk=name/alias)
> >> >> > > Example (dc=name, disk=name/alias)
> >> >> > > Example (sd=name, disk=name/alias)
> >> >> >
> >> >> > it's not about accepting both name/alias, it's about missing
> >> >> > ability
> >> >> > to identify your resource in collection.
> >> >> >
> >> >> > > For floating/shared on the same SD/DC/VM I would suggest a
> >> >> > > warning
> >> >> > > if there is a duplicate in the system - not enforcement.
> >> >> >
> >> >> > ok, lets assume we WARN user that his disk's name is not
> >> >> > unique,
> >> >> > how
> >> >> > user will pick the unique name?
> >> >> > implementing own code checking if new name (he wants to use)
> >> >> > is
> >> >> > unique or not?
> >> >> >
> >> >> > - this is business logic, not user's prerogative.
> >> >> >
> >> >> > > There is a difference between best practice and being
> >> >> > > enforcing
> >> >> > > up
> >> >> > > to the level that it annoys some of the users.
> >> >> >
> >> >> > simon, when you register to email, you have to try N times
> >> >> > till
> >> >> > you
> >> >> > find unique username,
> >> >> > is it convenient? absolutely NO, is it annoying? YES, but you
> >> >> > forced
> >> >> > doing that so
> >> >> > system will be able to identify you,
> >> >> >
> >> >> > it's no different in any way, good software protects
> >> >> > user/itself
> >> >> > even
> >> >> > in cost of convenience,
> >> >> >
> >> >> > bottom line
> >> >> > ===========
> >> >> >
> >> >> > - i think as long as disk not shared/floating it can have any
> >> >> > name
> >> >> > - in a minute disk designation changed to shared, name
> >> >> > uniqueness
> >> >> > should be forced (by the engine)
> >> >> > - when importing vm with shared disks, name uniqueness should
> >> >> > be
> >> >> > forced
> >> >> > - when creating vm from template with shared disk, name
> >> >> > uniqueness
> >> >> > should be forced
> >> >> > - alias should be changed back to name (in sake of
> >> >> > consistency)
> >> >> > - /api/disks collection should support searching disks by
> >> >> > name
> >> >> > (in
> >> >> > sake of consistency)
> >> >> >
> >> >> >
> >> >> > thoughts?
> >> >>
> >> >> Please look at the previous comment, that just can't work in
> >> >> the
> >> >> multi-tenancy case.
> >> >> Name should not be unique, the warning is for the admin only,
> >> >> from
> >> >> the user portal a warning should be issues only if the user
> >> >> provides
> >> >> same name twice.
> >> >>
> >> >>
> >> >> >
> >> >> > >
> >> >> > >>
> >> >> > >>
> >> >> > >> --
> >> >> > >>
> >> >> > >> Michael Pasternak
> >> >> > >> RedHat, ENG-Virtualization R&D
> >> >> > >> _______________________________________________
> >> >> > >> Engine-devel mailing list
> >> >> > >> Engine-devel at ovirt.org
> >> >> > >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >> >> > >>
> >> >> >
> >> >> >
> >> >> > --
> >> >> >
> >> >> > Michael Pasternak
> >> >> > RedHat, ENG-Virtualization R&D
> >> >> > _______________________________________________
> >> >> > Engine-devel mailing list
> >> >> > Engine-devel at ovirt.org
> >> >> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >> >> >
> >> >>
> >> > _______________________________________________
> >> > Engine-devel mailing list
> >> > Engine-devel at ovirt.org
> >> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>
> 


From medievalist at gmail.com  Tue Oct 23 18:41:15 2012
From: medievalist at gmail.com (Charlie)
Date: Tue, 23 Oct 2012 14:41:15 -0400
Subject: [Engine-devel] alias in disk instead of name
In-Reply-To: <1638221000.5207513.1351015665244.JavaMail.root@redhat.com>
References: <CAJb3uA5Z8YOqaWhaPZVpKrwcUM2LzR+H8N8wYLu3Ao4OrsUKFw@mail.gmail.com>
	<1638221000.5207513.1351015665244.JavaMail.root@redhat.com>
Message-ID: <CAJb3uA4GXLJ=2tnLigQ8R5qraWdL8MGN91dHW0PNBA0-7t9LZA@mail.gmail.com>

Very good points, Simon.  I do usually think in terms of large data
centers, but certainly not on the scale of cloud service providers!
Not yet, anyway.

It wouldn't be hard to restructure the algorithm as lockless, but if
you're really anticipating a scenario where hundreds of thousands of
users are all going to try to simultaneously create the same name,
there's (at least theoretically) a nasty edge case where one user
loops on name prompts until he goes nuts and throws the computer out
the window.

--Chaarlie

On Tue, Oct 23, 2012 at 2:07 PM, Simon Grinberg <simon at redhat.com> wrote:
>
>
> ----- Original Message -----
>> From: "Charlie" <medievalist at gmail.com>
>> To: "Simon Grinberg" <simon at redhat.com>
>> Cc: "engine-devel" <engine-devel at ovirt.org>
>> Sent: Tuesday, October 23, 2012 7:53:10 PM
>> Subject: Re: [Engine-devel] alias in disk instead of name
>>
>> Why not something like this?
>>
>> (pseudocode, using dot for string concatenation):
>>
>> $name_prefix = "vmdrive"
>> $name = get_last_used($name_prefix)
>> $already_in_use = $TRUE
>>
>> while $already_in_use {
>>      prompt "Name of thing? [$name] ", $name
>>      if name_used($name) {
>>          while name_used($name) {
>>             increment_number($name)
>>          }
>>      } else {
>>          $already_in_use = FALSE
>>      }
>> }
>>
>> do_whatever_you_do_with($name)
>>
>> store_last_used($name)
>>
>> end
>>
>>
>> The increment_number() routine checks to see if the last character is
>> numeric, and if it is, increments the leftmost contiguous numeric
>> portion of the string.  Otherwise it appends the number zero.
>>
>> This does not allow everyone to get any name they want, but you can't
>> ever satisfy that demand.  It supplies reasonable defaults very
>> quickly and it allows people who want really descriptive names to try
>> as many as they like.
>>
>> The code's built the funny way it is so that you can corrupt the db
>> that holds the last_used numbers or interrupt the process halfway
>> through and it still works, only slower, and it should tend to fix
>> its
>> own db on the fly when possible.
>>
>> There's no provision for simultaneous creation, but that wouldn't be
>> horribly hard to add, just put a lock on the resource holding
>> last_used numbers.
>>
>> You'd want to reimplement in the most efficient and readable way for
>> your programming language of choice.
>>
>> Did that make any sense?  I did it off the top of my head, so it
>> could
>> be terribly lame when I look at it tomorrow ;).
>
> Please don't look at it as pure programming item, nor as a single user in a small data center - in this respect you are right.
> Let's got to a huge organization or to the cloud.
>
> In multi tenant environment this lock means that every time a user tries to change a disk name - all the others are stack
> Don't forget we are discussing thousands of VMs - I'll hate to have this kind of lock just to allow for unique disk names. This is one of the reasons you use UUID to really identify the object in the DB, since it's suppose to guarantee uniqueness without the need to lock everything.
>
> And again - please look at this as an end user, why do I care that other users had decided they are going to use the same name as me? This is my human readable name and I want to choose what ever I like without considering other users. What is this self service portal worth if I can't name my VMs and Disks as I'd like to, oblivious to others?
>
> At the end of day, you want oVirt to be useful and scalable - and not just code wise correct.
>
>
>>
>> --Charlie
>>
>> On Tue, Oct 23, 2012 at 1:10 PM, Simon Grinberg <simon at redhat.com>
>> wrote:
>> >
>> >
>> > ----- Original Message -----
>> >> From: "Charlie" <medievalist at gmail.com>
>> >> To: "Simon Grinberg" <simon at redhat.com>
>> >> Cc: "engine-devel" <engine-devel at ovirt.org>
>> >> Sent: Tuesday, October 23, 2012 6:51:35 PM
>> >> Subject: Re: [Engine-devel] alias in disk instead of name
>> >>
>> >> OK, only because you asked...
>> >>
>> >> Provide default unique names, so that users can just press enter
>> >> if
>> >> names don't matter to them.  That way you obviate the entire
>> >> argument;
>> >> people who need special naming can have it, and everybody else has
>> >> a
>> >> single extra keypress or mouseclick at naming time, and searching
>> >> works well enough.
>> >>
>> >> You can name the first one vmdrive0 and increment the numeric part
>> >> each time a new drive is created.  Iterating until an unused name
>> >> is
>> >> found isn't so computationally expensive that anyone should weep,
>> >> especially if you store the last used number and do an
>> >> incrementing
>> >> sanity check against it at naming time.
>> >
>> > Let's say the above solved all conflicts when coming to create a
>> > new disk, it does seems so.
>> >
>> > Let's say that import/export if names conflict can be solved in a
>> > reasonable way - for example forcing (somehow and without
>> > bothering the user too much) a rename of the disk (How would you
>> > know if the conflicting name id auto-generated so can be replaced
>> > or user provided?, you'll have to resort to
>> > non-that-human-look-alike-name)
>> >
>> > How does it solve the multi-tenancy use case?
>> > I'm tenant A, setting up a quorum disk for my two VMs - so I call
>> > this disk simply quorum.
>> > Now comes tenant B, he is also setting up a quorum disk, so he
>> > tries to call his disk quorum
>> >
>> > But no,
>> > He'll get a popup that this name is already taken - bad luck buddy.
>> > Now he needs to guess the next available name? Would you build in
>> > algorithm to suggest alternatives?
>> > Why should tenant B care in the first place that tenant A also
>> > wanted to call his disk 'quorum'?
>> >
>> > Same with the VM name - but that is given for now, though I hope to
>> > convince it should change in the future.
>> >
>> > What I'm trying to say here - infrastructure is for the admin - so
>> > you can force uniqueness
>> > Resources like, disks and Virtual Machine belong to the end user
>> > thus you should let them determine their own names without being
>> > restricted by users of the system.
>> >
>> >
>> >
>> >>
>> >> People expect names to have significance, and we like it when they
>> >> have both unique and non-unique parts.  It's part of our human
>> >> heritage.  Maybe whales and dolphins don't care.
>> >
>> >
>> >
>> >>
>> >> --Charlie
>> >>
>> >> On Tue, Oct 23, 2012 at 4:36 AM, Simon Grinberg <simon at redhat.com>
>> >> wrote:
>> >> >
>> >> > We need more thoughts here from others, there are two different
>> >> > approaches on the table and more opinions are welcomed.
>> >> > If there are API consumers on this list then your view is more
>> >> > then
>> >> > welcomed.
>> >> >
>> >> > Thanks,
>> >> > Simon.
>> >> >
>> >> > ----- Original Message -----
>> >> >> From: "Simon Grinberg" <simon at redhat.com>
>> >> >> To: "Michael Pasternak" <mpastern at redhat.com>
>> >> >> Cc: "engine-devel" <engine-devel at ovirt.org>
>> >> >> Sent: Monday, October 22, 2012 10:50:02 AM
>> >> >> Subject: Re: [Engine-devel] alias in disk instead of name
>> >> >>
>> >> >>
>> >> >>
>> >> >> ----- Original Message -----
>> >> >> > From: "Michael Pasternak" <mpastern at redhat.com>
>> >> >> > To: "Simon Grinberg" <simon at redhat.com>
>> >> >> > Cc: "engine-devel" <engine-devel at ovirt.org>
>> >> >> > 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" <mpastern at redhat.com>
>> >> >> > >> To: "Simon Grinberg" <simon at redhat.com>
>> >> >> > >> Cc: "engine-devel" <engine-devel at ovirt.org>
>> >> >> > >> 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" <mpastern at redhat.com>
>> >> >> > >>>> To: "Simon Grinberg" <simon at redhat.com>
>> >> >> > >>>> Cc: "engine-devel" <engine-devel at ovirt.org>
>> >> >> > >>>> 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" <mpastern at redhat.com>
>> >> >> > >>>>>>> To: "engine-devel" <engine-devel at ovirt.org>
>> >> >> > >>>>>>> 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 talking about /search,
>> >> >> > search is available only at /api/disks (i.e shared disks,
>> >> >> > vm/template.disks is
>> >> >> > irrelevant to this discussion)
>> >> >>
>> >> >> Nope I do not, but I think that our perspectives differ.
>> >> >> You are looking at it as strictly design issue. You have a
>> >> >> collection
>> >> >> of entities and you want a human readable search, thus you are
>> >> >> trying to force (rightfully) from your point of view a unique
>> >> >> alias/name for those.
>> >> >>
>> >> >> I taking the end user perspective, and user experience
>> >> >> 1. Majority of the disks have no meaning outside of a VM scope.
>> >> >> 2. There are fractions of the disks that are usually shared
>> >> >> (this
>> >> >> is
>> >> >> the nature of shared disks)
>> >> >> 3. There are fractions of floating, most of the floating will
>> >> >> be a
>> >> >> transient state, while you are moving disks around.
>> >> >>
>> >> >> What I'm trying to say that forcing a user to provide a unique
>> >> >> name
>> >> >> per disk is a huge bother.
>> >> >> And again in the multi tenancy case, you can't enforce a unique
>> >> >> alias
>> >> >> in the system.
>> >> >>
>> >> >> What will you say to the user in the error message?
>> >> >> Sorry you can't use this alias since another user that is
>> >> >> sharing
>> >> >> the
>> >> >> system with you already provided that name? And yes we know you
>> >> >> can't see that other disk, and it you don't care about the
>> >> >> other
>> >> >> user, but still you can't use your alias since this is how our
>> >> >> platform designed.
>> >> >>
>> >> >> The meaning is that you must allow a for a more sophisticated
>> >> >> search.
>> >> >> Yes even in the context of the disks tab. Disks are not really
>> >> >> stand
>> >> >> alone entities, and if we keep to strict conventions like - in
>> >> >> any
>> >> >> collection an entity name must be unique, then you are making
>> >> >> the
>> >> >> system hardly usable for many users.
>> >> >>
>> >> >> So a search in disks should include other 'properties' (and yes
>> >> >> I
>> >> >> know those are not disk properties, but this is how a user will
>> >> >> look
>> >> >> at it) like owner,quota,vm,storage domain, etc.
>> >> >>
>> >> >> To some up - what should be unique are UUIDs of an entities,
>> >> >> and
>> >> >> infrastructure entities names (within the same scope) - all the
>> >> >> rest
>> >> >> must not.
>> >> >>
>> >> >>
>> >> >> >
>> >> >> > >
>> >> >> > >>
>> >> >> > >>>
>> >> >> > >>>>
>> >> >> > >>>>> Would you change these on import/export?
>> >> >> > >>>>
>> >> >> > >>>> would you mind elaborating on this?
>> >> >> > >>>
>> >> >> > >>> Yes,
>> >> >> > >>>
>> >> >> > >>> You are already facing a problem when importing VMs that
>> >> >> > >>> already
>> >> >> > >>> have the same name, now you increasing the problem for
>> >> >> > >>> disks
>> >> >> > >>> that
>> >> >> > >>> have the same alias. for same name we force clone if you
>> >> >> > >>> want
>> >> >> > >>> to
>> >> >> > >>> import. Why for clone just because of a disk alias (this
>> >> >> > >>> implies
>> >> >> > >>> collapse snapshots ATM) or even bother the user with
>> >> >> > >>> renaming
>> >> >> > >>> disks that he does not care about the name so he just
>> >> >> > >>> gave
>> >> >> > >>> disk
>> >> >> > >>> 1,
>> >> >> > >>> 2, 3 and so on?
>> >> >> > >>
>> >> >> > >> i see your point, but then we leave no option for the user
>> >> >> > >> to
>> >> >> > >> locate
>> >> >> > >> the disk,
>> >> >> > >> simply because he doesn't have unique identifier,
>> >> >> > >>
>> >> >> > >> just imagine user A creating disk and calling it X,
>> >> >> > >> then user B creating disk and calling it X, they on
>> >> >> > >> different
>> >> >> > >> domains etc., and now both want to use disk X,
>> >> >> > >>
>> >> >> > >> how they can figure out which one to pick?, by SD, by
>> >> >> > >> size?
>> >> >> > >> agree
>> >> >> > >> this is doesn't look well..., even more than that -
>> >> >> > >> someone
>> >> >> > >> may
>> >> >> > >> call
>> >> >> > >> this "bad design"...
>> >> >> > >
>> >> >> > > This is why the search should accept more then the name.
>> >> >> > > Example (vm=name, disk=name/alias)
>> >> >> > > Example (dc=name, disk=name/alias)
>> >> >> > > Example (sd=name, disk=name/alias)
>> >> >> >
>> >> >> > it's not about accepting both name/alias, it's about missing
>> >> >> > ability
>> >> >> > to identify your resource in collection.
>> >> >> >
>> >> >> > > For floating/shared on the same SD/DC/VM I would suggest a
>> >> >> > > warning
>> >> >> > > if there is a duplicate in the system - not enforcement.
>> >> >> >
>> >> >> > ok, lets assume we WARN user that his disk's name is not
>> >> >> > unique,
>> >> >> > how
>> >> >> > user will pick the unique name?
>> >> >> > implementing own code checking if new name (he wants to use)
>> >> >> > is
>> >> >> > unique or not?
>> >> >> >
>> >> >> > - this is business logic, not user's prerogative.
>> >> >> >
>> >> >> > > There is a difference between best practice and being
>> >> >> > > enforcing
>> >> >> > > up
>> >> >> > > to the level that it annoys some of the users.
>> >> >> >
>> >> >> > simon, when you register to email, you have to try N times
>> >> >> > till
>> >> >> > you
>> >> >> > find unique username,
>> >> >> > is it convenient? absolutely NO, is it annoying? YES, but you
>> >> >> > forced
>> >> >> > doing that so
>> >> >> > system will be able to identify you,
>> >> >> >
>> >> >> > it's no different in any way, good software protects
>> >> >> > user/itself
>> >> >> > even
>> >> >> > in cost of convenience,
>> >> >> >
>> >> >> > bottom line
>> >> >> > ===========
>> >> >> >
>> >> >> > - i think as long as disk not shared/floating it can have any
>> >> >> > name
>> >> >> > - in a minute disk designation changed to shared, name
>> >> >> > uniqueness
>> >> >> > should be forced (by the engine)
>> >> >> > - when importing vm with shared disks, name uniqueness should
>> >> >> > be
>> >> >> > forced
>> >> >> > - when creating vm from template with shared disk, name
>> >> >> > uniqueness
>> >> >> > should be forced
>> >> >> > - alias should be changed back to name (in sake of
>> >> >> > consistency)
>> >> >> > - /api/disks collection should support searching disks by
>> >> >> > name
>> >> >> > (in
>> >> >> > sake of consistency)
>> >> >> >
>> >> >> >
>> >> >> > thoughts?
>> >> >>
>> >> >> Please look at the previous comment, that just can't work in
>> >> >> the
>> >> >> multi-tenancy case.
>> >> >> Name should not be unique, the warning is for the admin only,
>> >> >> from
>> >> >> the user portal a warning should be issues only if the user
>> >> >> provides
>> >> >> same name twice.
>> >> >>
>> >> >>
>> >> >> >
>> >> >> > >
>> >> >> > >>
>> >> >> > >>
>> >> >> > >> --
>> >> >> > >>
>> >> >> > >> Michael Pasternak
>> >> >> > >> RedHat, ENG-Virtualization R&D
>> >> >> > >> _______________________________________________
>> >> >> > >> Engine-devel mailing list
>> >> >> > >> Engine-devel at ovirt.org
>> >> >> > >> http://lists.ovirt.org/mailman/listinfo/engine-devel
>> >> >> > >>
>> >> >> >
>> >> >> >
>> >> >> > --
>> >> >> >
>> >> >> > Michael Pasternak
>> >> >> > RedHat, ENG-Virtualization R&D
>> >> >> > _______________________________________________
>> >> >> > Engine-devel mailing list
>> >> >> > Engine-devel at ovirt.org
>> >> >> > http://lists.ovirt.org/mailman/listinfo/engine-devel
>> >> >> >
>> >> >>
>> >> > _______________________________________________
>> >> > Engine-devel mailing list
>> >> > Engine-devel at ovirt.org
>> >> > http://lists.ovirt.org/mailman/listinfo/engine-devel
>> >>
>>


From Christopher.Morrissey at netapp.com  Tue Oct 23 19:36:27 2012
From: Christopher.Morrissey at netapp.com (Morrissey, Christopher)
Date: Tue, 23 Oct 2012 19:36:27 +0000
Subject: [Engine-devel] UI Plugins: PoC patch revision 6 now available
In-Reply-To: <392790588.11440655.1351013711839.JavaMail.root@redhat.com>
References: <D290AD8432118048947689BA3AE8A9B3EA0073@SACEXCMBX04-PRD.hq.netapp.com>
	<392790588.11440655.1351013711839.JavaMail.root@redhat.com>
Message-ID: <D290AD8432118048947689BA3AE8A9B3EA0742@SACEXCMBX04-PRD.hq.netapp.com>

Hi Vojtech,

It looks like I?m going to be in training all next week and will unfortunately NOT be able to take on the work to implement the ?show dialog with content loaded from given URL? plugin API function as I had hoped. This is something we really need for revision 7. Of the items in your list for inclusion, the sub-tab frame plugin is the least necessary for us. The rest of the items are all pretty important.

Let me know if any of this is a problem or if we can shift things around to get them in the right order.

-Chris

From: Vojtech Szocs [mailto:vszocs at redhat.com]
Sent: Tuesday, October 23, 2012 1:35 PM
To: Morrissey, Christopher
Cc: engine-devel
Subject: Re: [Engine-devel] UI Plugins: PoC patch revision 6 now available

Hi Chris,

well, I planned to implement simple "show dialog with content loaded from given URL" plugin API function some time ago, but then I thought you might be experimenting with it already :) please feel free to work on that, we can include it into PoC revision 7.

Regarding planned items for revision 7, here's my current list (feel free to add/modify things here if necessary):

  *   "add custom sub tab" plugin API function, with initial sub tab implementation showing content of the given URL (we can add more tab types later on, e.g. form-based or table-based tab)
  *   "add custom task to task pane" plugin API function, requires some UiCommon integration coding (I will handle this)
  *   "show dialog with content loaded from given URL" plugin API function, initial implementation could simply open new browser popup window using window.open (but any other approach is fine as well)
  *   integration with REST API, e.g. "obtain REST API authentication token" plugin API function, maybe also some API for performing actual HTTP REST calls?



As for the Engine REST API authentication token, need to learn more about it, as WebAdmin GUI currently uses GWT RPC instead of REST API when communicating with the backend.



You also mentioned that "we can make calls from our server into the REST API" - I assume this will be used together with "custom content for tab/dialog" plugin API functionality? (Otherwise I'd say the UI Plugin itself could make REST API calls on its own..)



Regards,

Vojtech

________________________________
From: "Christopher Morrissey" <Christopher.Morrissey at netapp.com>
To: "Vojtech Szocs" <vszocs at redhat.com>, "engine-devel" <engine-devel at ovirt.org>
Sent: Monday, October 22, 2012 5:25:53 PM
Subject: RE: [Engine-devel] UI Plugins: PoC patch revision 6 now available
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.

-Chris

From: engine-devel-bounces at ovirt.org [mailto:engine-devel-bounces at 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 <OVIRT_HOME>/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, but this isn't relevant in our case).

In contrast with traditional class-based object-oriented languages, JavaScript supports OOP through prototype-based programming model (https://developer.mozilla.org/en-US/docs/JavaScript/Introduction_to_Object-Oriented_JavaScript). At the same time, JavaScript language is dynamically-typed and therefore doesn't support traditional concept of interface in OOP, it uses "duck typing" technique instead (http://en.wikipedia.org/wiki/Duck_typing).

The simplest way to provide an object that "implements the given interface" in JavaScript is to use "duck typing" technique: providing an object that contains well-known functions. In UI plugin infrastructure, I call this concept "interface object", represented by org.ovirt.engine.ui.webadmin.plugin.jsni.JsInterfaceObject class. Unlike the traditional concept of interface abstract type in object-oriented languages, an "interface object" does not necessarily have to declare all functions of the given interface in order to "implement" such interface. In fact, an empty object can be used as a valid "interface object". Missing functions will be simply treated as empty (no-op) functions. Furthermore, an "interface object" can "implement" multiple interfaces by declaring functions of those interfaces (interface composition).

Getting back to "addMainTabActionButton" API, here's a sample code that adds new button to "Host" main tab data grid, as part of UiInit event handler function:

UiInit: function() {
    api.addMainTabActionButton('Host', 'Single-Host Action',

        // Action button interface object
        // All functions receive currently selected item(s) as function arguments
        {

            // Called when the user clicks the button
            onClick: function() {
                // Calling 'arguments[0]' is safe, because onClick() can be called
                // only when exactly one item is currently selected in the data grid
                window.alert('Selected host entity ID = ' + arguments[0].entityId);
            },

            // Returning 'true' means the button is enabled (clickable)
            // Returning 'false' means the button is disabled (non-clickable)
            // Default value = 'true'
            isEnabled: function() {
                // Enable button only when exactly one item is selected
                return arguments.length == 1;
            },

            // Returning 'true' means the button is visible
            // Returning 'false' means the button is hidden
            // Default value = 'true'
            isAccessible: function() {
                // Always show the button in the corresponding data grid
                return true;
            }

        }

    );
}

As mentioned above, all functions of an interface object are optional. For functions expecting return value, default value is defined by UI plugin infrastructure. For example:

  *   onClick - no default value (no return value expected)
  *   isEnabled / isAccessible - default value "true" (boolean return value expected)

Note: UI plugin infrastructure checks the actual return value type, and uses default value in case the function returned something of wrong (unexpected) type.

In the example above, "currently selected item(s)" maps to JSON-like representations of business entities currently selected in the corresponding data grid. For now, the entity representation is quite simple and same for all entity types:

{ entityId: "[BusinessEntityGuidAsString]" }

In future, we will create specific JSON-like representations for specific business entities, in compliance with Engine REST API entity structure.

For a more extensive example of using "addMainTabActionButton" API, please see the attached "addMainTabActionButton.html.example" file.
________________________________

2. Improved plugin API function: addMainTab

The "addMainTab" API was improved to address following issues:

  *   "addMainTab" can now be called at any moment during UI plugin runtime, given that the plugin is allowed invoke plugin API functions (plugin is either INITIALIZING or IN_USE).
Previously, "addMainTab" worked reliably only when called from within UiInit event handler function.
Currently, it's possible to call "addMainTab" at any moment, e.g. from within some other event handler function (after UiInit has completed).

  *   "addMainTab" now retains "active" tab (highlighted tab GUI).
"addMainTab" works by adding new tab component (GWTP presenter proxy) and refreshing main tab panel GUI by removing all related tabs and re-adding them again.
This logic is handled by org.ovirt.engine.ui.common.presenter.DynamicTabContainerPresenter class, which makes sure that "active" tab is retained even after main tab panel was refreshed.
Furthermore, custom main tab implementation now displays the content of the given URL through HTML iframe element.
________________________________

3. Improved native JavaScript function handling (GWT JSNI)

This patch introduces org.ovirt.engine.ui.webadmin.plugin.jsni.JsFunction and org.ovirt.engine.ui.webadmin.plugin.jsni.JsFunctionResultHelper classes providing Java abstraction for invoking native JavaScript functions. These classes follow the general contract of "interface object" as mentioned above.

JsFunctionResultHelper is particularly useful when dealing with functions which are expected to return value of a certain type. Too bad standard GWT JSNI classes don't provide such abstraction for working with native functions out-of-the-box...
________________________________

4. ActionPanel and ActionTable type hierarchy refactoring (related to "addMainTabActionButton" API)

Previously, AbstractActionPanel and AbstractActionTable classes didn't implement any reasonable interface that would allow other components (client-side UI plugin infrastructure) to depend on their functionality in a loosely-coupled manner. This would make code that implements "addMainTabActionButton" API "ugly": main tab view interface would have to reference AbstractActionTable class directly. In MVP design pattern, view interface should avoid referencing specific GWT Widget classes directly.

This patch introduces new interfaces for ActionPanel and ActionTable components while eliminating code redundancy (duplicate or unnecessary code).
________________________________

5. ActionPanel type hierarchy refactoring (related to "addMainTab" API)

Since org.ovirt.engine.ui.common.presenter.DynamicTabContainerPresenter defines new DynamicTabPanel interface that extends standard GWTP TabPanel interface, some refactoring had to be done in related ActionPanel classes.

This patch makes sure that both org.ovirt.engine.ui.common.widget.tab.AbstractTabPanel (widget) and org.ovirt.engine.ui.common.view.AbstractTabPanelView (view) support DynamicTabPanel interface.

Note that for now, only main tab panel (org.ovirt.engine.ui.webadmin.section.main.presenter.MainTabPanelPresenter) supports dynamic tabs within its view.
________________________________

Where is addSubTab API function?

Implementing "addSubTab" API requires some more changes, and I didn't want to delay this PoC patch just because of it...

Here's a sample code that illustrates proposed "addSubTab" API usage:

UiInit: function() {
    api.addSubTab('Host',        // entityTypeName
        'Custom Host Sub Tab',   // label
        'custom-host-sub-tab',   // historyToken
        'http://www.ovirt.org/', // contentUrl

        // Sub tab interface object
        // All functions receive currently selected item(s)
        // within the main tab data grid as function arguments
        {

            // Returning 'true' means the sub tab is visible
            // Returning 'false' means the sub tab is hidden
            // Default value = 'true'
            isAccessible: function() {
                return arguments.length == 1 && arguments[0].entityId == '<MyHostEntityId>';
            }

        }

    );
}

As part of "addSubTab" API implementation, I'll refactor custom main tab components, in order to use one "tab type" for both main and sub tabs.

Currently, we have one (and only one) "tab type" - a tab that shows content of the given URL through HTML iframe element.

We could also create new "tab types", e.g. form-based tab that shows key/value pairs (IMHO this could be quite useful for custom sub tabs).
________________________________

Let me know what you think!

Cheers,
Vojtech

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20121023/73ff5cae/attachment.html>

From abaron at redhat.com  Tue Oct 23 20:52:35 2012
From: abaron at redhat.com (Ayal Baron)
Date: Tue, 23 Oct 2012 16:52:35 -0400 (EDT)
Subject: [Engine-devel] [vdsm] unmanaged devices thrown into 'custom'
 feature
In-Reply-To: <20121023114103.GP17071@redhat.com>
Message-ID: <2094921670.872190.1351025555185.JavaMail.root@redhat.com>



----- Original Message -----
> On Tue, Oct 23, 2012 at 05:53:20AM -0400, Doron Fediuck wrote:
> > 
> > 
> > ----- Original Message -----
> > > From: "Livnat Peer" <lpeer at redhat.com>
> > > To: "Dan Kenigsberg" <danken at redhat.com>
> > > Cc: engine-devel at ovirt.org, "Genadi Chereshnya"
> > > <gcheresh at redhat.com>, vdsm-devel at fedorahosted.org
> > > Sent: Monday, October 22, 2012 8:29:20 AM
> > > Subject: Re: [Engine-devel] [vdsm] unmanaged devices thrown into
> > > 'custom' feature
> > > 
> > > On 21/10/12 23:49, Dan Kenigsberg wrote:
> > > > On Sun, Oct 21, 2012 at 11:57:10AM -0400, Eli Mesika wrote:
> > > >>
> > > >>
> > > >> ----- Original Message -----
> > > >>> From: "Yair Zaslavsky" <yzaslavs at redhat.com>
> > > >>> To: "Livnat Peer" <lpeer at redhat.com>
> > > >>> Cc: "Genadi Chereshnya" <gcheresh at redhat.com>,
> > > >>> engine-devel at ovirt.org, vdsm-devel at fedorahosted.org
> > > >>> Sent: Sunday, October 21, 2012 5:38:54 PM
> > > >>> Subject: Re: [Engine-devel] unmanaged devices thrown into
> > > >>> 'custom' feature
> > > >>>
> > > >>>
> > > >>>
> > > >>> ----- Original Message -----
> > > >>>> From: "Livnat Peer" <lpeer at redhat.com>
> > > >>>> To: "Dan Kenigsberg" <danken at redhat.com>
> > > >>>> Cc: "Genadi Chereshnya" <gcheresh at redhat.com>,
> > > >>>> engine-devel at ovirt.org, vdsm-devel at fedorahosted.org
> > > >>>> Sent: Sunday, October 21, 2012 5:18:31 PM
> > > >>>> Subject: Re: [Engine-devel] unmanaged devices thrown into
> > > >>>> 'custom'
> > > >>>> feature
> > > >>>>
> > > >>>> On 21/10/12 16:42, Dan Kenigsberg wrote:
> > > >>>>> I have just noticed that when a VM is started for the
> > > >>>>> second
> > > >>>>> time,
> > > >>>>> Engine
> > > >>>>> issues the "create" vdsm verb with some information
> > > >>>>> regarding
> > > >>>>> "unmanaged" devices (an example is shown below[1]) in the
> > > >>>>> 'custom'
> > > >>>>> propery bag.
> > > >>>>>
> > > >>>>> I'm surprised about this, as I was not aware of this usage
> > > >>>>> of
> > > >>>>> the
> > > >>>>> 'custom' dictionary, and Vdsm is not doing anything with
> > > >>>>> the
> > > >>>>> data.
> > > >>>>>
> > > >>>>
> > > >>>> If I recall correctly the idea of passing the unmanaged
> > > >>>> devices
> > > >>>> data
> > > >>>> in
> > > >>>> the custom property was to enable managing stable device
> > > >>>> addresses
> > > >>>> in
> > > >>>> the hooks (to devices that were added to the VM via hooks
> > > >>>> from
> > > >>>> the
> > > >>>> first
> > > >>>> place), so this info is there not for VDSM use.
> > > >>>> For example if you add a device in a hook it will be kept in
> > > >>>> the
> > > >>>> engine
> > > >>>> as a non managed device. later when starting the VM again
> > > >>>> you
> > > >>>> would
> > > >>>> like
> > > >>>> to assign the same device address to your device, and you
> > > >>>> can do
> > > >>>> so
> > > >>>> because you have access to the original address in the
> > > >>>> custom
> > > >>>> properties
> > > >>>> of the VM.
> > > >>>
> > > >>> This is exactly what Eli has explained Gendai and Dan today.
> > > > 
> > > > (I was asking here because I did not understand the verbal
> > > > explanation.)
> > > > 
> > > >>
> > > >> This is taken from the Stable Device Address design in
> > > >> http://wiki.ovirt.org/wiki/Features/Design/StableDeviceAddresses
> > > >>
> > > >> Unmanaged Device
> > > >> -----------------
> > > >> Unmanaged Device will be supported in the new format and will
> > > >> include all unhandled devices as sound/controller/etc and
> > > >> future
> > > >> devices. Those devices will be persistent and will have Type ,
> > > >> SubType (device specific) and an Address. For 3.1 an unmanaged
> > > >> Device is not exposed to any GUI/REST API. Unmanaged devices
> > > >> are
> > > >> passed to vdsm inside a Custom property. VDSM in it turn is
> > > >> passing this as is for possible hook processing.
> > > > 
> > > > Thanks for the elaboration. Too bad that I've missed this issue
> > > > before.
> > > > 
> > > > Are you aware of any hook making use of this?  I hope that hook
> > > > writers
> > > > are not using APIs that are not documented in vdsmd(8).
> > > > 
> > > > It seems as a classic case where a generic bag interface is
> > > > coerced
> > > > into
> > > > an awkward partially-documented interface.
> > > > 
> > > > I think that a better approach would have been to pass all
> > > > devices
> > > > (managed and unmanaged alike) in the 'devices' property, and
> > > > let
> > > > vdsm
> > > > expose whatever is needed to the before_vm_start hook.
> > > > 
> > > > Maybe we can still do this.
> > > 
> > > That was the original idea but Ayal objected and I think Igor did
> > > not
> > > like it as well...
> > > 
> > 
> > +2.
> > The original design had an 'unmanaged' (or generic) device type,
> > and all
> > devices should have been normalized. But as explained, this was
> > strongly
> > rejected in the VDSM side, causing Eli write some special handling
> > for this anomaly.
> 
> Can someone (Ayal?) explain the rejection on Vdsm side?
> Hiding part of the API in the custom propery bag requires strong
> reasoning indeed.

It's not hiding anything.
Today vdsm passes the libvirt xml to the hooks + the custom properties.
If you pass 'non-managed devices' through the devices API then basically you're saying to vdsm 'here is a bunch of things I want you to ignore but be a sport and pass it on to the hooks'.
Last I checked, that mechanism is custom properties.  I don't see any reason to add another one.


> 
> Dan.
> 
> _______________________________________________
> vdsm-devel mailing list
> vdsm-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
> 


From iheim at redhat.com  Wed Oct 24 03:54:51 2012
From: iheim at redhat.com (Itamar Heim)
Date: Wed, 24 Oct 2012 05:54:51 +0200
Subject: [Engine-devel] [vdsm] unmanaged devices thrown into 'custom'
 feature
In-Reply-To: <2094921670.872190.1351025555185.JavaMail.root@redhat.com>
References: <2094921670.872190.1351025555185.JavaMail.root@redhat.com>
Message-ID: <5087668B.6050708@redhat.com>

On 10/23/2012 10:52 PM, Ayal Baron wrote:
>
>
> ----- Original Message -----
>> On Tue, Oct 23, 2012 at 05:53:20AM -0400, Doron Fediuck wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Livnat Peer" <lpeer at redhat.com>
>>>> To: "Dan Kenigsberg" <danken at redhat.com>
>>>> Cc: engine-devel at ovirt.org, "Genadi Chereshnya"
>>>> <gcheresh at redhat.com>, vdsm-devel at fedorahosted.org
>>>> Sent: Monday, October 22, 2012 8:29:20 AM
>>>> Subject: Re: [Engine-devel] [vdsm] unmanaged devices thrown into
>>>> 'custom' feature
>>>>
>>>> On 21/10/12 23:49, Dan Kenigsberg wrote:
>>>>> On Sun, Oct 21, 2012 at 11:57:10AM -0400, Eli Mesika wrote:
>>>>>>
>>>>>>
>>>>>> ----- Original Message -----
>>>>>>> From: "Yair Zaslavsky" <yzaslavs at redhat.com>
>>>>>>> To: "Livnat Peer" <lpeer at redhat.com>
>>>>>>> Cc: "Genadi Chereshnya" <gcheresh at redhat.com>,
>>>>>>> engine-devel at ovirt.org, vdsm-devel at fedorahosted.org
>>>>>>> Sent: Sunday, October 21, 2012 5:38:54 PM
>>>>>>> Subject: Re: [Engine-devel] unmanaged devices thrown into
>>>>>>> 'custom' feature
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ----- Original Message -----
>>>>>>>> From: "Livnat Peer" <lpeer at redhat.com>
>>>>>>>> To: "Dan Kenigsberg" <danken at redhat.com>
>>>>>>>> Cc: "Genadi Chereshnya" <gcheresh at redhat.com>,
>>>>>>>> engine-devel at ovirt.org, vdsm-devel at fedorahosted.org
>>>>>>>> Sent: Sunday, October 21, 2012 5:18:31 PM
>>>>>>>> Subject: Re: [Engine-devel] unmanaged devices thrown into
>>>>>>>> 'custom'
>>>>>>>> feature
>>>>>>>>
>>>>>>>> On 21/10/12 16:42, Dan Kenigsberg wrote:
>>>>>>>>> I have just noticed that when a VM is started for the
>>>>>>>>> second
>>>>>>>>> time,
>>>>>>>>> Engine
>>>>>>>>> issues the "create" vdsm verb with some information
>>>>>>>>> regarding
>>>>>>>>> "unmanaged" devices (an example is shown below[1]) in the
>>>>>>>>> 'custom'
>>>>>>>>> propery bag.
>>>>>>>>>
>>>>>>>>> I'm surprised about this, as I was not aware of this usage
>>>>>>>>> of
>>>>>>>>> the
>>>>>>>>> 'custom' dictionary, and Vdsm is not doing anything with
>>>>>>>>> the
>>>>>>>>> data.
>>>>>>>>>
>>>>>>>>
>>>>>>>> If I recall correctly the idea of passing the unmanaged
>>>>>>>> devices
>>>>>>>> data
>>>>>>>> in
>>>>>>>> the custom property was to enable managing stable device
>>>>>>>> addresses
>>>>>>>> in
>>>>>>>> the hooks (to devices that were added to the VM via hooks
>>>>>>>> from
>>>>>>>> the
>>>>>>>> first
>>>>>>>> place), so this info is there not for VDSM use.
>>>>>>>> For example if you add a device in a hook it will be kept in
>>>>>>>> the
>>>>>>>> engine
>>>>>>>> as a non managed device. later when starting the VM again
>>>>>>>> you
>>>>>>>> would
>>>>>>>> like
>>>>>>>> to assign the same device address to your device, and you
>>>>>>>> can do
>>>>>>>> so
>>>>>>>> because you have access to the original address in the
>>>>>>>> custom
>>>>>>>> properties
>>>>>>>> of the VM.
>>>>>>>
>>>>>>> This is exactly what Eli has explained Gendai and Dan today.
>>>>>
>>>>> (I was asking here because I did not understand the verbal
>>>>> explanation.)
>>>>>
>>>>>>
>>>>>> This is taken from the Stable Device Address design in
>>>>>> http://wiki.ovirt.org/wiki/Features/Design/StableDeviceAddresses
>>>>>>
>>>>>> Unmanaged Device
>>>>>> -----------------
>>>>>> Unmanaged Device will be supported in the new format and will
>>>>>> include all unhandled devices as sound/controller/etc and
>>>>>> future
>>>>>> devices. Those devices will be persistent and will have Type ,
>>>>>> SubType (device specific) and an Address. For 3.1 an unmanaged
>>>>>> Device is not exposed to any GUI/REST API. Unmanaged devices
>>>>>> are
>>>>>> passed to vdsm inside a Custom property. VDSM in it turn is
>>>>>> passing this as is for possible hook processing.
>>>>>
>>>>> Thanks for the elaboration. Too bad that I've missed this issue
>>>>> before.
>>>>>
>>>>> Are you aware of any hook making use of this?  I hope that hook
>>>>> writers
>>>>> are not using APIs that are not documented in vdsmd(8).
>>>>>
>>>>> It seems as a classic case where a generic bag interface is
>>>>> coerced
>>>>> into
>>>>> an awkward partially-documented interface.
>>>>>
>>>>> I think that a better approach would have been to pass all
>>>>> devices
>>>>> (managed and unmanaged alike) in the 'devices' property, and
>>>>> let
>>>>> vdsm
>>>>> expose whatever is needed to the before_vm_start hook.
>>>>>
>>>>> Maybe we can still do this.
>>>>
>>>> That was the original idea but Ayal objected and I think Igor did
>>>> not
>>>> like it as well...
>>>>
>>>
>>> +2.
>>> The original design had an 'unmanaged' (or generic) device type,
>>> and all
>>> devices should have been normalized. But as explained, this was
>>> strongly
>>> rejected in the VDSM side, causing Eli write some special handling
>>> for this anomaly.
>>
>> Can someone (Ayal?) explain the rejection on Vdsm side?
>> Hiding part of the API in the custom propery bag requires strong
>> reasoning indeed.
>
> It's not hiding anything.
> Today vdsm passes the libvirt xml to the hooks + the custom properties.
> If you pass 'non-managed devices' through the devices API then basically you're saying to vdsm 'here is a bunch of things I want you to ignore but be a sport and pass it on to the hooks'.
> Last I checked, that mechanism is custom properties.  I don't see any reason to add another one.

1. this means hooks don't actually get the unmanaged devices today?
2. custom property are to pass parameters to the hook user can 
reasonably control. device management should not be part of that if not 
strictly related to the hook (from user's side).
3. I'm guessing (didn't get this first time i read your answer), you are 
hinting the unmanaged devices should be passed as a custom property to 
vdsm, auto generated by engine?


From iheim at redhat.com  Wed Oct 24 04:01:53 2012
From: iheim at redhat.com (Itamar Heim)
Date: Wed, 24 Oct 2012 06:01:53 +0200
Subject: [Engine-devel] alias in disk instead of name
In-Reply-To: <1638221000.5207513.1351015665244.JavaMail.root@redhat.com>
References: <1638221000.5207513.1351015665244.JavaMail.root@redhat.com>
Message-ID: <50876831.1030309@redhat.com>

On 10/23/2012 08:07 PM, Simon Grinberg wrote:
>
>
> ----- Original Message -----
>> From: "Charlie" <medievalist at gmail.com>
>> To: "Simon Grinberg" <simon at redhat.com>
>> Cc: "engine-devel" <engine-devel at ovirt.org>
>> Sent: Tuesday, October 23, 2012 7:53:10 PM
>> Subject: Re: [Engine-devel] alias in disk instead of name
>>
>> Why not something like this?
>>
>> (pseudocode, using dot for string concatenation):
>>
>> $name_prefix = "vmdrive"
>> $name = get_last_used($name_prefix)
>> $already_in_use = $TRUE
>>
>> while $already_in_use {
>>       prompt "Name of thing? [$name] ", $name
>>       if name_used($name) {
>>           while name_used($name) {
>>              increment_number($name)
>>           }
>>       } else {
>>           $already_in_use = FALSE
>>       }
>> }
>>
>> do_whatever_you_do_with($name)
>>
>> store_last_used($name)
>>
>> end
>>
>>
>> The increment_number() routine checks to see if the last character is
>> numeric, and if it is, increments the leftmost contiguous numeric
>> portion of the string.  Otherwise it appends the number zero.
>>
>> This does not allow everyone to get any name they want, but you can't
>> ever satisfy that demand.  It supplies reasonable defaults very
>> quickly and it allows people who want really descriptive names to try
>> as many as they like.
>>
>> The code's built the funny way it is so that you can corrupt the db
>> that holds the last_used numbers or interrupt the process halfway
>> through and it still works, only slower, and it should tend to fix
>> its
>> own db on the fly when possible.
>>
>> There's no provision for simultaneous creation, but that wouldn't be
>> horribly hard to add, just put a lock on the resource holding
>> last_used numbers.
>>
>> You'd want to reimplement in the most efficient and readable way for
>> your programming language of choice.
>>
>> Did that make any sense?  I did it off the top of my head, so it
>> could
>> be terribly lame when I look at it tomorrow ;).
>
> Please don't look at it as pure programming item, nor as a single user in a small data center - in this respect you are right.
> Let's got to a huge organization or to the cloud.
>
> In multi tenant environment this lock means that every time a user tries to change a disk name - all the others are stack
> Don't forget we are discussing thousands of VMs - I'll hate to have this kind of lock just to allow for unique disk names. This is one of the reasons you use UUID to really identify the object in the DB, since it's suppose to guarantee uniqueness without the need to lock everything.
>
> And again - please look at this as an end user, why do I care that other users had decided they are going to use the same name as me? This is my human readable name and I want to choose what ever I like without considering other users. What is this self service portal worth if I can't name my VMs and Disks as I'd like to, oblivious to others?
>
> At the end of day, you want oVirt to be useful and scalable - and not just code wise correct.


how about KISS?
vm name is unique.
disk name is unique in vm.
treat disk name for search as vm.name + "-" + disk.name

as for name uniqueness for multi tenants, yes, something we need to fix.
would love for more inputs on how people see tenants and users interact 
in ovirt (can a user be part of more than a single tenant for example, 
but force user to choose tenant when they login if they have more than one)?

>
>
>>
>> --Charlie
>>
>> On Tue, Oct 23, 2012 at 1:10 PM, Simon Grinberg <simon at redhat.com>
>> wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Charlie" <medievalist at gmail.com>
>>>> To: "Simon Grinberg" <simon at redhat.com>
>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
>>>> Sent: Tuesday, October 23, 2012 6:51:35 PM
>>>> Subject: Re: [Engine-devel] alias in disk instead of name
>>>>
>>>> OK, only because you asked...
>>>>
>>>> Provide default unique names, so that users can just press enter
>>>> if
>>>> names don't matter to them.  That way you obviate the entire
>>>> argument;
>>>> people who need special naming can have it, and everybody else has
>>>> a
>>>> single extra keypress or mouseclick at naming time, and searching
>>>> works well enough.
>>>>
>>>> You can name the first one vmdrive0 and increment the numeric part
>>>> each time a new drive is created.  Iterating until an unused name
>>>> is
>>>> found isn't so computationally expensive that anyone should weep,
>>>> especially if you store the last used number and do an
>>>> incrementing
>>>> sanity check against it at naming time.
>>>
>>> Let's say the above solved all conflicts when coming to create a
>>> new disk, it does seems so.
>>>
>>> Let's say that import/export if names conflict can be solved in a
>>> reasonable way - for example forcing (somehow and without
>>> bothering the user too much) a rename of the disk (How would you
>>> know if the conflicting name id auto-generated so can be replaced
>>> or user provided?, you'll have to resort to
>>> non-that-human-look-alike-name)
>>>
>>> How does it solve the multi-tenancy use case?
>>> I'm tenant A, setting up a quorum disk for my two VMs - so I call
>>> this disk simply quorum.
>>> Now comes tenant B, he is also setting up a quorum disk, so he
>>> tries to call his disk quorum
>>>
>>> But no,
>>> He'll get a popup that this name is already taken - bad luck buddy.
>>> Now he needs to guess the next available name? Would you build in
>>> algorithm to suggest alternatives?
>>> Why should tenant B care in the first place that tenant A also
>>> wanted to call his disk 'quorum'?
>>>
>>> Same with the VM name - but that is given for now, though I hope to
>>> convince it should change in the future.
>>>
>>> What I'm trying to say here - infrastructure is for the admin - so
>>> you can force uniqueness
>>> Resources like, disks and Virtual Machine belong to the end user
>>> thus you should let them determine their own names without being
>>> restricted by users of the system.
>>>
>>>
>>>
>>>>
>>>> People expect names to have significance, and we like it when they
>>>> have both unique and non-unique parts.  It's part of our human
>>>> heritage.  Maybe whales and dolphins don't care.
>>>
>>>
>>>
>>>>
>>>> --Charlie
>>>>
>>>> On Tue, Oct 23, 2012 at 4:36 AM, Simon Grinberg <simon at redhat.com>
>>>> wrote:
>>>>>
>>>>> We need more thoughts here from others, there are two different
>>>>> approaches on the table and more opinions are welcomed.
>>>>> If there are API consumers on this list then your view is more
>>>>> then
>>>>> welcomed.
>>>>>
>>>>> Thanks,
>>>>> Simon.
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Simon Grinberg" <simon at redhat.com>
>>>>>> To: "Michael Pasternak" <mpastern at redhat.com>
>>>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
>>>>>> Sent: Monday, October 22, 2012 10:50:02 AM
>>>>>> Subject: Re: [Engine-devel] alias in disk instead of name
>>>>>>
>>>>>>
>>>>>>
>>>>>> ----- Original Message -----
>>>>>>> From: "Michael Pasternak" <mpastern at redhat.com>
>>>>>>> To: "Simon Grinberg" <simon at redhat.com>
>>>>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
>>>>>>> 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" <mpastern at redhat.com>
>>>>>>>>> To: "Simon Grinberg" <simon at redhat.com>
>>>>>>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
>>>>>>>>> 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" <mpastern at redhat.com>
>>>>>>>>>>> To: "Simon Grinberg" <simon at redhat.com>
>>>>>>>>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
>>>>>>>>>>> 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" <mpastern at redhat.com>
>>>>>>>>>>>>>> To: "engine-devel" <engine-devel at ovirt.org>
>>>>>>>>>>>>>> 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 talking about /search,
>>>>>>> search is available only at /api/disks (i.e shared disks,
>>>>>>> vm/template.disks is
>>>>>>> irrelevant to this discussion)
>>>>>>
>>>>>> Nope I do not, but I think that our perspectives differ.
>>>>>> You are looking at it as strictly design issue. You have a
>>>>>> collection
>>>>>> of entities and you want a human readable search, thus you are
>>>>>> trying to force (rightfully) from your point of view a unique
>>>>>> alias/name for those.
>>>>>>
>>>>>> I taking the end user perspective, and user experience
>>>>>> 1. Majority of the disks have no meaning outside of a VM scope.
>>>>>> 2. There are fractions of the disks that are usually shared
>>>>>> (this
>>>>>> is
>>>>>> the nature of shared disks)
>>>>>> 3. There are fractions of floating, most of the floating will
>>>>>> be a
>>>>>> transient state, while you are moving disks around.
>>>>>>
>>>>>> What I'm trying to say that forcing a user to provide a unique
>>>>>> name
>>>>>> per disk is a huge bother.
>>>>>> And again in the multi tenancy case, you can't enforce a unique
>>>>>> alias
>>>>>> in the system.
>>>>>>
>>>>>> What will you say to the user in the error message?
>>>>>> Sorry you can't use this alias since another user that is
>>>>>> sharing
>>>>>> the
>>>>>> system with you already provided that name? And yes we know you
>>>>>> can't see that other disk, and it you don't care about the
>>>>>> other
>>>>>> user, but still you can't use your alias since this is how our
>>>>>> platform designed.
>>>>>>
>>>>>> The meaning is that you must allow a for a more sophisticated
>>>>>> search.
>>>>>> Yes even in the context of the disks tab. Disks are not really
>>>>>> stand
>>>>>> alone entities, and if we keep to strict conventions like - in
>>>>>> any
>>>>>> collection an entity name must be unique, then you are making
>>>>>> the
>>>>>> system hardly usable for many users.
>>>>>>
>>>>>> So a search in disks should include other 'properties' (and yes
>>>>>> I
>>>>>> know those are not disk properties, but this is how a user will
>>>>>> look
>>>>>> at it) like owner,quota,vm,storage domain, etc.
>>>>>>
>>>>>> To some up - what should be unique are UUIDs of an entities,
>>>>>> and
>>>>>> infrastructure entities names (within the same scope) - all the
>>>>>> rest
>>>>>> must not.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Would you change these on import/export?
>>>>>>>>>>>
>>>>>>>>>>> would you mind elaborating on this?
>>>>>>>>>>
>>>>>>>>>> Yes,
>>>>>>>>>>
>>>>>>>>>> You are already facing a problem when importing VMs that
>>>>>>>>>> already
>>>>>>>>>> have the same name, now you increasing the problem for
>>>>>>>>>> disks
>>>>>>>>>> that
>>>>>>>>>> have the same alias. for same name we force clone if you
>>>>>>>>>> want
>>>>>>>>>> to
>>>>>>>>>> import. Why for clone just because of a disk alias (this
>>>>>>>>>> implies
>>>>>>>>>> collapse snapshots ATM) or even bother the user with
>>>>>>>>>> renaming
>>>>>>>>>> disks that he does not care about the name so he just
>>>>>>>>>> gave
>>>>>>>>>> disk
>>>>>>>>>> 1,
>>>>>>>>>> 2, 3 and so on?
>>>>>>>>>
>>>>>>>>> i see your point, but then we leave no option for the user
>>>>>>>>> to
>>>>>>>>> locate
>>>>>>>>> the disk,
>>>>>>>>> simply because he doesn't have unique identifier,
>>>>>>>>>
>>>>>>>>> just imagine user A creating disk and calling it X,
>>>>>>>>> then user B creating disk and calling it X, they on
>>>>>>>>> different
>>>>>>>>> domains etc., and now both want to use disk X,
>>>>>>>>>
>>>>>>>>> how they can figure out which one to pick?, by SD, by
>>>>>>>>> size?
>>>>>>>>> agree
>>>>>>>>> this is doesn't look well..., even more than that -
>>>>>>>>> someone
>>>>>>>>> may
>>>>>>>>> call
>>>>>>>>> this "bad design"...
>>>>>>>>
>>>>>>>> This is why the search should accept more then the name.
>>>>>>>> Example (vm=name, disk=name/alias)
>>>>>>>> Example (dc=name, disk=name/alias)
>>>>>>>> Example (sd=name, disk=name/alias)
>>>>>>>
>>>>>>> it's not about accepting both name/alias, it's about missing
>>>>>>> ability
>>>>>>> to identify your resource in collection.
>>>>>>>
>>>>>>>> For floating/shared on the same SD/DC/VM I would suggest a
>>>>>>>> warning
>>>>>>>> if there is a duplicate in the system - not enforcement.
>>>>>>>
>>>>>>> ok, lets assume we WARN user that his disk's name is not
>>>>>>> unique,
>>>>>>> how
>>>>>>> user will pick the unique name?
>>>>>>> implementing own code checking if new name (he wants to use)
>>>>>>> is
>>>>>>> unique or not?
>>>>>>>
>>>>>>> - this is business logic, not user's prerogative.
>>>>>>>
>>>>>>>> There is a difference between best practice and being
>>>>>>>> enforcing
>>>>>>>> up
>>>>>>>> to the level that it annoys some of the users.
>>>>>>>
>>>>>>> simon, when you register to email, you have to try N times
>>>>>>> till
>>>>>>> you
>>>>>>> find unique username,
>>>>>>> is it convenient? absolutely NO, is it annoying? YES, but you
>>>>>>> forced
>>>>>>> doing that so
>>>>>>> system will be able to identify you,
>>>>>>>
>>>>>>> it's no different in any way, good software protects
>>>>>>> user/itself
>>>>>>> even
>>>>>>> in cost of convenience,
>>>>>>>
>>>>>>> bottom line
>>>>>>> ===========
>>>>>>>
>>>>>>> - i think as long as disk not shared/floating it can have any
>>>>>>> name
>>>>>>> - in a minute disk designation changed to shared, name
>>>>>>> uniqueness
>>>>>>> should be forced (by the engine)
>>>>>>> - when importing vm with shared disks, name uniqueness should
>>>>>>> be
>>>>>>> forced
>>>>>>> - when creating vm from template with shared disk, name
>>>>>>> uniqueness
>>>>>>> should be forced
>>>>>>> - alias should be changed back to name (in sake of
>>>>>>> consistency)
>>>>>>> - /api/disks collection should support searching disks by
>>>>>>> name
>>>>>>> (in
>>>>>>> sake of consistency)
>>>>>>>
>>>>>>>
>>>>>>> thoughts?
>>>>>>
>>>>>> Please look at the previous comment, that just can't work in
>>>>>> the
>>>>>> multi-tenancy case.
>>>>>> Name should not be unique, the warning is for the admin only,
>>>>>> from
>>>>>> the user portal a warning should be issues only if the user
>>>>>> provides
>>>>>> same name twice.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>>
>>>>>>>>> Michael Pasternak
>>>>>>>>> RedHat, ENG-Virtualization R&D
>>>>>>>>> _______________________________________________
>>>>>>>>> Engine-devel mailing list
>>>>>>>>> Engine-devel at ovirt.org
>>>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>> Michael Pasternak
>>>>>>> RedHat, ENG-Virtualization R&D
>>>>>>> _______________________________________________
>>>>>>> Engine-devel mailing list
>>>>>>> Engine-devel at ovirt.org
>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> Engine-devel mailing list
>>>>> Engine-devel at ovirt.org
>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>
>>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>




From simon at redhat.com  Wed Oct 24 08:24:20 2012
From: simon at redhat.com (Simon Grinberg)
Date: Wed, 24 Oct 2012 04:24:20 -0400 (EDT)
Subject: [Engine-devel] alias in disk instead of name
In-Reply-To: <50876831.1030309@redhat.com>
Message-ID: <1952920135.5438345.1351067060563.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Simon Grinberg" <simon at redhat.com>
> Cc: "Ewoud Kohl van Wijngaarden" <ewoud at kohlvanwijngaarden.nl>, "engine-devel" <engine-devel at ovirt.org>
> Sent: Wednesday, October 24, 2012 6:01:53 AM
> Subject: Re: [Engine-devel] alias in disk instead of name
> 
> On 10/23/2012 08:07 PM, Simon Grinberg wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Charlie" <medievalist at gmail.com>
> >> To: "Simon Grinberg" <simon at redhat.com>
> >> Cc: "engine-devel" <engine-devel at ovirt.org>
> >> Sent: Tuesday, October 23, 2012 7:53:10 PM
> >> Subject: Re: [Engine-devel] alias in disk instead of name
> >>
> >> Why not something like this?
> >>
> >> (pseudocode, using dot for string concatenation):
> >>
> >> $name_prefix = "vmdrive"
> >> $name = get_last_used($name_prefix)
> >> $already_in_use = $TRUE
> >>
> >> while $already_in_use {
> >>       prompt "Name of thing? [$name] ", $name
> >>       if name_used($name) {
> >>           while name_used($name) {
> >>              increment_number($name)
> >>           }
> >>       } else {
> >>           $already_in_use = FALSE
> >>       }
> >> }
> >>
> >> do_whatever_you_do_with($name)
> >>
> >> store_last_used($name)
> >>
> >> end
> >>
> >>
> >> The increment_number() routine checks to see if the last character
> >> is
> >> numeric, and if it is, increments the leftmost contiguous numeric
> >> portion of the string.  Otherwise it appends the number zero.
> >>
> >> This does not allow everyone to get any name they want, but you
> >> can't
> >> ever satisfy that demand.  It supplies reasonable defaults very
> >> quickly and it allows people who want really descriptive names to
> >> try
> >> as many as they like.
> >>
> >> The code's built the funny way it is so that you can corrupt the
> >> db
> >> that holds the last_used numbers or interrupt the process halfway
> >> through and it still works, only slower, and it should tend to fix
> >> its
> >> own db on the fly when possible.
> >>
> >> There's no provision for simultaneous creation, but that wouldn't
> >> be
> >> horribly hard to add, just put a lock on the resource holding
> >> last_used numbers.
> >>
> >> You'd want to reimplement in the most efficient and readable way
> >> for
> >> your programming language of choice.
> >>
> >> Did that make any sense?  I did it off the top of my head, so it
> >> could
> >> be terribly lame when I look at it tomorrow ;).
> >
> > Please don't look at it as pure programming item, nor as a single
> > user in a small data center - in this respect you are right.
> > Let's got to a huge organization or to the cloud.
> >
> > In multi tenant environment this lock means that every time a user
> > tries to change a disk name - all the others are stack
> > Don't forget we are discussing thousands of VMs - I'll hate to have
> > this kind of lock just to allow for unique disk names. This is one
> > of the reasons you use UUID to really identify the object in the
> > DB, since it's suppose to guarantee uniqueness without the need to
> > lock everything.
> >
> > And again - please look at this as an end user, why do I care that
> > other users had decided they are going to use the same name as me?
> > This is my human readable name and I want to choose what ever I
> > like without considering other users. What is this self service
> > portal worth if I can't name my VMs and Disks as I'd like to,
> > oblivious to others?
> >
> > At the end of day, you want oVirt to be useful and scalable - and
> > not just code wise correct.
> 
> 
> how about KISS?
> vm name is unique.
> disk name is unique in vm.
> treat disk name for search as vm.name + "-" + disk.name

Now we are getting somewhere since this is similar to my original proposal of adding vm/domain/other to the disk search criteria

But let me take your proposal a bit farther.
I think it's safe to assume / force that tenants don't share quotas, meaning a tenant may have multiple quotas but a quota may belong to a single tenant (and I know the term tenant is not well defined, but let's assume the under any definition for this discussion it may be collapsed to a collection of users and groups)

The problem is now reduced to keeping to scope boundaries.

Quota name is unique in the scope of a data center
VM name is unique in the scope of a quota (note that I intentionally don't say cluster)
Disk name is unique in the scope of a VM or the floating scope

Now to search is easy
For VMs -> dc.quota.vm
For disks -> dc.quota.vm.disk
Or For floating -> dc.quota.floating.disk 
Shared disk may be accessed from any of the attached VMs

when Quota is off -> you get the simple equivalent 
For VMs -> dc.vm
For disks -> dc.vm.disk
Or For floating -> dc.floating.disk 
Shared disk may be accessed from any of the attached VMs

This is KISS, scalable, and I believe easy to understand by any user of oVirt.

And in order not to bother users with providing a unique name in the scope we should always offer a name for the user to just click OK or modify, similar (may be even simpler) algorithm to what Charlie suggested.
The above is for:
1. New disk
2. Detach disk from the last VM, meaning it becomes floating, if the name is not unique, then suggest a free name based on the current name.

A nice benefit of the above is that the user may use wild cards, and get a list of matches filtered by his permissions.
Example:
admin searching for dc-X.quota-Y.* gets a list of all the floating disks in the quota
user searching for the same  will get a list of all the floating disks he has permissions on.

Thoughts? 


> 
> as for name uniqueness for multi tenants, yes, something we need to
> fix.
> would love for more inputs on how people see tenants and users
> interact
> in ovirt (can a user be part of more than a single tenant for
> example,
> but force user to choose tenant when they login if they have more
> than one)?
> 
> >
> >
> >>
> >> --Charlie
> >>
> >> On Tue, Oct 23, 2012 at 1:10 PM, Simon Grinberg <simon at redhat.com>
> >> wrote:
> >>>
> >>>
> >>> ----- Original Message -----
> >>>> From: "Charlie" <medievalist at gmail.com>
> >>>> To: "Simon Grinberg" <simon at redhat.com>
> >>>> Cc: "engine-devel" <engine-devel at ovirt.org>
> >>>> Sent: Tuesday, October 23, 2012 6:51:35 PM
> >>>> Subject: Re: [Engine-devel] alias in disk instead of name
> >>>>
> >>>> OK, only because you asked...
> >>>>
> >>>> Provide default unique names, so that users can just press enter
> >>>> if
> >>>> names don't matter to them.  That way you obviate the entire
> >>>> argument;
> >>>> people who need special naming can have it, and everybody else
> >>>> has
> >>>> a
> >>>> single extra keypress or mouseclick at naming time, and
> >>>> searching
> >>>> works well enough.
> >>>>
> >>>> You can name the first one vmdrive0 and increment the numeric
> >>>> part
> >>>> each time a new drive is created.  Iterating until an unused
> >>>> name
> >>>> is
> >>>> found isn't so computationally expensive that anyone should
> >>>> weep,
> >>>> especially if you store the last used number and do an
> >>>> incrementing
> >>>> sanity check against it at naming time.
> >>>
> >>> Let's say the above solved all conflicts when coming to create a
> >>> new disk, it does seems so.
> >>>
> >>> Let's say that import/export if names conflict can be solved in a
> >>> reasonable way - for example forcing (somehow and without
> >>> bothering the user too much) a rename of the disk (How would you
> >>> know if the conflicting name id auto-generated so can be replaced
> >>> or user provided?, you'll have to resort to
> >>> non-that-human-look-alike-name)
> >>>
> >>> How does it solve the multi-tenancy use case?
> >>> I'm tenant A, setting up a quorum disk for my two VMs - so I call
> >>> this disk simply quorum.
> >>> Now comes tenant B, he is also setting up a quorum disk, so he
> >>> tries to call his disk quorum
> >>>
> >>> But no,
> >>> He'll get a popup that this name is already taken - bad luck
> >>> buddy.
> >>> Now he needs to guess the next available name? Would you build in
> >>> algorithm to suggest alternatives?
> >>> Why should tenant B care in the first place that tenant A also
> >>> wanted to call his disk 'quorum'?
> >>>
> >>> Same with the VM name - but that is given for now, though I hope
> >>> to
> >>> convince it should change in the future.
> >>>
> >>> What I'm trying to say here - infrastructure is for the admin -
> >>> so
> >>> you can force uniqueness
> >>> Resources like, disks and Virtual Machine belong to the end user
> >>> thus you should let them determine their own names without being
> >>> restricted by users of the system.
> >>>
> >>>
> >>>
> >>>>
> >>>> People expect names to have significance, and we like it when
> >>>> they
> >>>> have both unique and non-unique parts.  It's part of our human
> >>>> heritage.  Maybe whales and dolphins don't care.
> >>>
> >>>
> >>>
> >>>>
> >>>> --Charlie
> >>>>
> >>>> On Tue, Oct 23, 2012 at 4:36 AM, Simon Grinberg
> >>>> <simon at redhat.com>
> >>>> wrote:
> >>>>>
> >>>>> We need more thoughts here from others, there are two different
> >>>>> approaches on the table and more opinions are welcomed.
> >>>>> If there are API consumers on this list then your view is more
> >>>>> then
> >>>>> welcomed.
> >>>>>
> >>>>> Thanks,
> >>>>> Simon.
> >>>>>
> >>>>> ----- Original Message -----
> >>>>>> From: "Simon Grinberg" <simon at redhat.com>
> >>>>>> To: "Michael Pasternak" <mpastern at redhat.com>
> >>>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
> >>>>>> Sent: Monday, October 22, 2012 10:50:02 AM
> >>>>>> Subject: Re: [Engine-devel] alias in disk instead of name
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> ----- Original Message -----
> >>>>>>> From: "Michael Pasternak" <mpastern at redhat.com>
> >>>>>>> To: "Simon Grinberg" <simon at redhat.com>
> >>>>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
> >>>>>>> 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" <mpastern at redhat.com>
> >>>>>>>>> To: "Simon Grinberg" <simon at redhat.com>
> >>>>>>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
> >>>>>>>>> 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" <mpastern at redhat.com>
> >>>>>>>>>>> To: "Simon Grinberg" <simon at redhat.com>
> >>>>>>>>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
> >>>>>>>>>>> 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" <mpastern at redhat.com>
> >>>>>>>>>>>>>> To: "engine-devel" <engine-devel at ovirt.org>
> >>>>>>>>>>>>>> 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 talking about /search,
> >>>>>>> search is available only at /api/disks (i.e shared disks,
> >>>>>>> vm/template.disks is
> >>>>>>> irrelevant to this discussion)
> >>>>>>
> >>>>>> Nope I do not, but I think that our perspectives differ.
> >>>>>> You are looking at it as strictly design issue. You have a
> >>>>>> collection
> >>>>>> of entities and you want a human readable search, thus you are
> >>>>>> trying to force (rightfully) from your point of view a unique
> >>>>>> alias/name for those.
> >>>>>>
> >>>>>> I taking the end user perspective, and user experience
> >>>>>> 1. Majority of the disks have no meaning outside of a VM
> >>>>>> scope.
> >>>>>> 2. There are fractions of the disks that are usually shared
> >>>>>> (this
> >>>>>> is
> >>>>>> the nature of shared disks)
> >>>>>> 3. There are fractions of floating, most of the floating will
> >>>>>> be a
> >>>>>> transient state, while you are moving disks around.
> >>>>>>
> >>>>>> What I'm trying to say that forcing a user to provide a unique
> >>>>>> name
> >>>>>> per disk is a huge bother.
> >>>>>> And again in the multi tenancy case, you can't enforce a
> >>>>>> unique
> >>>>>> alias
> >>>>>> in the system.
> >>>>>>
> >>>>>> What will you say to the user in the error message?
> >>>>>> Sorry you can't use this alias since another user that is
> >>>>>> sharing
> >>>>>> the
> >>>>>> system with you already provided that name? And yes we know
> >>>>>> you
> >>>>>> can't see that other disk, and it you don't care about the
> >>>>>> other
> >>>>>> user, but still you can't use your alias since this is how our
> >>>>>> platform designed.
> >>>>>>
> >>>>>> The meaning is that you must allow a for a more sophisticated
> >>>>>> search.
> >>>>>> Yes even in the context of the disks tab. Disks are not really
> >>>>>> stand
> >>>>>> alone entities, and if we keep to strict conventions like - in
> >>>>>> any
> >>>>>> collection an entity name must be unique, then you are making
> >>>>>> the
> >>>>>> system hardly usable for many users.
> >>>>>>
> >>>>>> So a search in disks should include other 'properties' (and
> >>>>>> yes
> >>>>>> I
> >>>>>> know those are not disk properties, but this is how a user
> >>>>>> will
> >>>>>> look
> >>>>>> at it) like owner,quota,vm,storage domain, etc.
> >>>>>>
> >>>>>> To some up - what should be unique are UUIDs of an entities,
> >>>>>> and
> >>>>>> infrastructure entities names (within the same scope) - all
> >>>>>> the
> >>>>>> rest
> >>>>>> must not.
> >>>>>>
> >>>>>>
> >>>>>>>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>> Would you change these on import/export?
> >>>>>>>>>>>
> >>>>>>>>>>> would you mind elaborating on this?
> >>>>>>>>>>
> >>>>>>>>>> Yes,
> >>>>>>>>>>
> >>>>>>>>>> You are already facing a problem when importing VMs that
> >>>>>>>>>> already
> >>>>>>>>>> have the same name, now you increasing the problem for
> >>>>>>>>>> disks
> >>>>>>>>>> that
> >>>>>>>>>> have the same alias. for same name we force clone if you
> >>>>>>>>>> want
> >>>>>>>>>> to
> >>>>>>>>>> import. Why for clone just because of a disk alias (this
> >>>>>>>>>> implies
> >>>>>>>>>> collapse snapshots ATM) or even bother the user with
> >>>>>>>>>> renaming
> >>>>>>>>>> disks that he does not care about the name so he just
> >>>>>>>>>> gave
> >>>>>>>>>> disk
> >>>>>>>>>> 1,
> >>>>>>>>>> 2, 3 and so on?
> >>>>>>>>>
> >>>>>>>>> i see your point, but then we leave no option for the user
> >>>>>>>>> to
> >>>>>>>>> locate
> >>>>>>>>> the disk,
> >>>>>>>>> simply because he doesn't have unique identifier,
> >>>>>>>>>
> >>>>>>>>> just imagine user A creating disk and calling it X,
> >>>>>>>>> then user B creating disk and calling it X, they on
> >>>>>>>>> different
> >>>>>>>>> domains etc., and now both want to use disk X,
> >>>>>>>>>
> >>>>>>>>> how they can figure out which one to pick?, by SD, by
> >>>>>>>>> size?
> >>>>>>>>> agree
> >>>>>>>>> this is doesn't look well..., even more than that -
> >>>>>>>>> someone
> >>>>>>>>> may
> >>>>>>>>> call
> >>>>>>>>> this "bad design"...
> >>>>>>>>
> >>>>>>>> This is why the search should accept more then the name.
> >>>>>>>> Example (vm=name, disk=name/alias)
> >>>>>>>> Example (dc=name, disk=name/alias)
> >>>>>>>> Example (sd=name, disk=name/alias)
> >>>>>>>
> >>>>>>> it's not about accepting both name/alias, it's about missing
> >>>>>>> ability
> >>>>>>> to identify your resource in collection.
> >>>>>>>
> >>>>>>>> For floating/shared on the same SD/DC/VM I would suggest a
> >>>>>>>> warning
> >>>>>>>> if there is a duplicate in the system - not enforcement.
> >>>>>>>
> >>>>>>> ok, lets assume we WARN user that his disk's name is not
> >>>>>>> unique,
> >>>>>>> how
> >>>>>>> user will pick the unique name?
> >>>>>>> implementing own code checking if new name (he wants to use)
> >>>>>>> is
> >>>>>>> unique or not?
> >>>>>>>
> >>>>>>> - this is business logic, not user's prerogative.
> >>>>>>>
> >>>>>>>> There is a difference between best practice and being
> >>>>>>>> enforcing
> >>>>>>>> up
> >>>>>>>> to the level that it annoys some of the users.
> >>>>>>>
> >>>>>>> simon, when you register to email, you have to try N times
> >>>>>>> till
> >>>>>>> you
> >>>>>>> find unique username,
> >>>>>>> is it convenient? absolutely NO, is it annoying? YES, but you
> >>>>>>> forced
> >>>>>>> doing that so
> >>>>>>> system will be able to identify you,
> >>>>>>>
> >>>>>>> it's no different in any way, good software protects
> >>>>>>> user/itself
> >>>>>>> even
> >>>>>>> in cost of convenience,
> >>>>>>>
> >>>>>>> bottom line
> >>>>>>> ===========
> >>>>>>>
> >>>>>>> - i think as long as disk not shared/floating it can have any
> >>>>>>> name
> >>>>>>> - in a minute disk designation changed to shared, name
> >>>>>>> uniqueness
> >>>>>>> should be forced (by the engine)
> >>>>>>> - when importing vm with shared disks, name uniqueness should
> >>>>>>> be
> >>>>>>> forced
> >>>>>>> - when creating vm from template with shared disk, name
> >>>>>>> uniqueness
> >>>>>>> should be forced
> >>>>>>> - alias should be changed back to name (in sake of
> >>>>>>> consistency)
> >>>>>>> - /api/disks collection should support searching disks by
> >>>>>>> name
> >>>>>>> (in
> >>>>>>> sake of consistency)
> >>>>>>>
> >>>>>>>
> >>>>>>> thoughts?
> >>>>>>
> >>>>>> Please look at the previous comment, that just can't work in
> >>>>>> the
> >>>>>> multi-tenancy case.
> >>>>>> Name should not be unique, the warning is for the admin only,
> >>>>>> from
> >>>>>> the user portal a warning should be issues only if the user
> >>>>>> provides
> >>>>>> same name twice.
> >>>>>>
> >>>>>>
> >>>>>>>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>>
> >>>>>>>>> Michael Pasternak
> >>>>>>>>> RedHat, ENG-Virtualization R&D
> >>>>>>>>> _______________________________________________
> >>>>>>>>> Engine-devel mailing list
> >>>>>>>>> Engine-devel at ovirt.org
> >>>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>>
> >>>>>>> Michael Pasternak
> >>>>>>> RedHat, ENG-Virtualization R&D
> >>>>>>> _______________________________________________
> >>>>>>> Engine-devel mailing list
> >>>>>>> Engine-devel at ovirt.org
> >>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>>>>>>
> >>>>>>
> >>>>> _______________________________________________
> >>>>> Engine-devel mailing list
> >>>>> Engine-devel at ovirt.org
> >>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>>>
> >>
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
> 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From ovedo at redhat.com  Wed Oct 24 08:46:50 2012
From: ovedo at redhat.com (Oved Ourfalli)
Date: Wed, 24 Oct 2012 04:46:50 -0400 (EDT)
Subject: [Engine-devel] UI Plugins: PoC patch revision 6 now available
In-Reply-To: <50863DDE.4020906@redhat.com>
Message-ID: <1094781798.24217819.1351068410177.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Christopher Morrissey" <Christopher.Morrissey at netapp.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Tuesday, October 23, 2012 8:49:02 AM
> Subject: 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?
> 

Yes.
What we planned to do is different than the jasper reports solution.
We planned to take the same session ID that the webadmin has, and pass it over to the REST API as session ID (as we added the REST session support - http://wiki.ovirt.org/wiki/Features/RESTSessionManagement).

The problem is that while previous versions of jboss allowed using the same session in two different webapps, it is no longer possible in jboss AS7,
so what we would need to do is to login once to the REST API with the credentials as used in webadmin, get the session ID from the cookie, and save it for further requests.

> Thanks,
>     Itamar
> 
> >
> > -Chris
> >
> > *From:*engine-devel-bounces at ovirt.org
> > [mailto:engine-devel-bounces at 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 <OVIRT_HOME>/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, but this isn't relevant in our case).
> >
> > In contrast with traditional class-based object-oriented languages,
> > JavaScript supports OOP through prototype-based programming model
> > (https://developer.mozilla.org/en-US/docs/JavaScript/Introduction_to_Object-Oriented_JavaScript).
> > At the same time, JavaScript language is dynamically-typed and
> > therefore
> > doesn't support traditional concept of interface in OOP, it uses
> > "duck
> > typing" technique instead
> > (http://en.wikipedia.org/wiki/Duck_typing).
> >
> > The simplest way to provide an object that "implements the given
> > interface" in JavaScript is to use "duck typing" technique:
> > providing an
> > object that contains well-known functions. In UI plugin
> > infrastructure,
> > I call this concept "interface object", represented by
> > org.ovirt.engine.ui.webadmin.plugin.jsni.JsInterfaceObject class.
> > Unlike
> > the traditional concept of interface abstract type in
> > object-oriented
> > languages, an "interface object" _does not necessarily have to
> > declare
> > all functions of the given interface_ in order to "implement" such
> > interface. In fact, an empty object can be used as a valid
> > "interface
> > object". Missing functions will be simply treated as empty (no-op)
> > functions. Furthermore, an "interface object" can "implement"
> > multiple
> > interfaces by declaring functions of those interfaces (interface
> > composition).
> >
> > Getting back to "addMainTabActionButton" API, here's a sample code
> > that
> > adds new button to "Host" main tab data grid, as part of UiInit
> > event
> > handler function:
> >
> > UiInit: *function*() {
> >      api.addMainTabActionButton('Host', 'Single-Host Action',
> >
> >          // Action button interface object
> >          // All functions receive currently selected item(s) as
> >          function
> > arguments
> >          {
> >
> >              // Called when the user clicks the button
> > onClick: *function*() {
> >                  // Calling 'arguments[0]' is safe, because
> >                  onClick()
> > can be called
> >                  // only when exactly one item is currently
> >                  selected in
> > the data grid
> >                  window.alert('Selected host entity ID = ' +
> > arguments[0].entityId);
> >              },
> >
> >              // Returning 'true' means the button is enabled
> >              (clickable)
> >              // Returning 'false' means the button is disabled
> > (non-clickable)
> >              // Default value = 'true'
> > isEnabled: *function*() {
> >                  // Enable button only when exactly one item is
> >                  selected
> > *return*arguments.length == 1;
> >              },
> >
> >              // Returning 'true' means the button is visible
> >              // Returning 'false' means the button is hidden
> >              // Default value = 'true'
> > isAccessible: *function*() {
> >                  // Always show the button in the corresponding
> >                  data grid
> > *return**true*;
> >              }
> >
> >          }
> >
> >      );
> > }
> >
> > As mentioned above, all functions of an interface object are
> > optional.
> > For functions expecting return value, default value is defined by
> > UI
> > plugin infrastructure. For example:
> >
> >   * onClick - no default value (no return value expected)
> >   * isEnabled / isAccessible - default value "true" (boolean return
> >     value expected)
> >
> > Note: UI plugin infrastructure checks the actual return value type,
> > and
> > uses default value in case the function returned something of wrong
> > (unexpected) type.
> >
> >
> > In the example above, "currently selected item(s)" maps to
> > JSON-like
> > representations of business entities currently selected in the
> > corresponding data grid. For now, the entity representation is
> > quite
> > simple and same for all entity types:
> >
> > { entityId: "[BusinessEntityGuidAsString]" }
> >
> > In future, we will create specific JSON-like representations for
> > specific business entities, in compliance with Engine REST API
> > entity
> > structure.
> >
> > For a more extensive example of using "addMainTabActionButton" API,
> > please see the attached "addMainTabActionButton.html.example" file.
> >
> > ------------------------------------------------------------------------
> >
> >
> > *2. Improved plugin API function: addMainTab
> > *
> > The "addMainTab" API was improved to address following issues:
> >
> >   * "addMainTab" can now be called at any moment during UI plugin
> >     runtime, given that the plugin is allowed invoke plugin API
> >     functions (plugin is either INITIALIZING or IN_USE).
> >     Previously, "addMainTab" worked reliably only when called from
> >     within UiInit event handler function.
> >     Currently, it's possible to call "addMainTab" at any moment,
> >     e.g.
> >     from within some other event handler function (after UiInit has
> >     completed).
> >
> >   * "addMainTab" now retains "active" tab (highlighted tab GUI).
> >     "addMainTab" works by adding new tab component (GWTP presenter
> >     proxy) and refreshing main tab panel GUI by removing all
> >     related
> >     tabs and re-adding them again.
> >     This logic is handled by
> >     org.ovirt.engine.ui.common.presenter.DynamicTabContainerPresenter
> >     class, which makes sure that "active" tab is retained even
> >     after
> >     main tab panel was refreshed.
> >
> > Furthermore, custom main tab implementation now displays the
> > content of
> > the given URL through HTML iframe element.
> >
> > ------------------------------------------------------------------------
> >
> >
> > *3. Improved native JavaScript function handling* (GWT JSNI)
> >
> > This patch introduces
> > org.ovirt.engine.ui.webadmin.plugin.jsni.JsFunction and
> > org.ovirt.engine.ui.webadmin.plugin.jsni.JsFunctionResultHelper
> > classes
> > providing Java abstraction for invoking native JavaScript
> > functions.
> > These classes follow the general contract of "interface object" as
> > mentioned above.
> >
> > JsFunctionResultHelper is particularly useful when dealing with
> > functions which are expected to return value of a certain type. Too
> > bad
> > standard GWT JSNI classes don't provide such abstraction for
> > working
> > with native functions out-of-the-box...
> >
> > ------------------------------------------------------------------------
> >
> >
> > *4. ActionPanel and ActionTable type hierarchy refactoring*
> > (related to
> > "addMainTabActionButton" API)*
> > *
> > Previously, AbstractActionPanel and AbstractActionTable classes
> > didn't
> > implement any reasonable interface that would allow other
> > components
> > (client-side UI plugin infrastructure) to depend on their
> > functionality
> > in a loosely-coupled manner. This would make code that implements
> > "addMainTabActionButton" API "ugly": main tab view interface would
> > have
> > to reference AbstractActionTable class directly. In MVP design
> > pattern,
> > view interface should avoid referencing specific GWT Widget classes
> > directly.
> >
> > This patch introduces new interfaces for ActionPanel and
> > ActionTable
> > components while eliminating code redundancy (duplicate or
> > unnecessary
> > code).
> >
> > ------------------------------------------------------------------------
> >
> >
> > *5. ActionPanel type hierarchy refactoring* (related to
> > "addMainTab" API)
> >
> > Since
> > org.ovirt.engine.ui.common.presenter.DynamicTabContainerPresenter
> > defines new DynamicTabPanel interface that extends standard GWTP
> > TabPanel interface, some refactoring had to be done in related
> > ActionPanel classes.
> >
> > This patch makes sure that both
> > org.ovirt.engine.ui.common.widget.tab.AbstractTabPanel (widget) and
> > org.ovirt.engine.ui.common.view.AbstractTabPanelView (view) support
> > DynamicTabPanel interface.
> >
> > Note that for now, only main tab panel
> > (org.ovirt.engine.ui.webadmin.section.main.presenter.MainTabPanelPresenter)
> > supports dynamic tabs within its view.
> >
> > ------------------------------------------------------------------------
> >
> >
> > *Where is addSubTab API function?*
> >
> > Implementing "addSubTab" API requires some more changes, and I
> > didn't
> > want to delay this PoC patch just because of it...
> >
> > Here's a sample code that illustrates proposed "addSubTab" API
> > usage:
> >
> > UiInit: *function*() {
> >      api.addSubTab('Host', // entityTypeName
> >          'Custom Host Sub Tab', // label
> >          'custom-host-sub-tab', // historyToken
> >          'http://www.ovirt.org/', // contentUrl
> >
> > // Sub tab interface object
> >          // All functions receive currently selected item(s)
> >          // within the main tab data grid as function arguments
> >          {
> >
> >              // Returning 'true' means the sub tab is visible
> >              // Returning 'false' means the sub tab is hidden
> >              // Default value = 'true'
> > isAccessible: *function*() {
> > *return*arguments.length == 1 && arguments[0].entityId ==
> > '<MyHostEntityId>';
> >              }
> >
> >          }
> >
> >      );
> > }
> >
> > As part of "addSubTab" API implementation, I'll refactor custom
> > main tab
> > components, in order to use one "tab type" for both main and sub
> > tabs.
> >
> > Currently, we have one (and only one) "tab type" - a tab that shows
> > content of the given URL through HTML iframe element.
> >
> > We could also create new "tab types", e.g. form-based tab that
> > shows
> > key/value pairs (IMHO this could be quite useful for custom sub
> > tabs).
> >
> > ------------------------------------------------------------------------
> >
> >
> > Let me know what you think!
> >
> > Cheers,
> > Vojtech
> >
> >
> >
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
> 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From yzaslavs at redhat.com  Wed Oct 24 09:32:16 2012
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Wed, 24 Oct 2012 05:32:16 -0400 (EDT)
Subject: [Engine-devel] AsyncTaskManager and the irsbroker
In-Reply-To: <1163133771.17075037.1347380854215.JavaMail.root@redhat.com>
Message-ID: <907077235.21147124.1351071136988.JavaMail.root@redhat.com>

Hi Laszlo,
Sorry for the very late response,
You are correct.
We have inefficient synchronization issues.
For example - I wonder whether we should have AsyncTaskManager instance per data center

Yair


----- Original Message -----
> From: "Laszlo Hornyak" <lhornyak at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>
> Sent: Tuesday, September 11, 2012 7:27:34 PM
> Subject: [Engine-devel] AsyncTaskManager and the irsbroker
> 
> hi,
> 
> I have just noticed that AsyncTaskManager is
> - almost all of the public methods are synchronized
> - and it is singleton
> - calling to VDS operations (line 291)
> 
> Therefore this may be a performance bottleneck. Even when you want to
> create an asynchronous task or query a task's state, you may have to
> wait till a remote vdsm responds. Would it be ok to remove the
> synchronization from e.g. the query-like methods? Or the one
> initiating remote calls?
> 
> Laszlo
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From dfediuck at redhat.com  Wed Oct 24 11:06:26 2012
From: dfediuck at redhat.com (Doron Fediuck)
Date: Wed, 24 Oct 2012 07:06:26 -0400 (EDT)
Subject: [Engine-devel] Question about hasMemoryToRunVM() in
 RunVmCommandBase
In-Reply-To: <CANDY9WNP77dtoMqUa9qokRUDsM+K5=WYzuYav_yCgbWXEhXF2Q@mail.gmail.com>
Message-ID: <1076764376.16688374.1351076786318.JavaMail.root@redhat.com>

----- Original Message -----
> From: "ly pan" <plysab at gmail.com>
> To: engine-devel at ovirt.org
> Sent: Thursday, October 18, 2012 2:43:35 PM
> Subject: [Engine-devel] Question about hasMemoryToRunVM() in RunVmCommandBase
> 
> Hi:
> 
> This is my test environment:
> hardware: Dell PowerEdge 2710 ,Memory 48G
> Software: OVirt engine 3.0 ,VDSM 4.9.4 ,kernel
> 2.6.32-279.2.1.el6.x86_64
> 
> 
> I create 100 vms from pool(each vm has 512M memory and has
> 1M memory garanteed, with guest_overhead = 65 and reserved_mem =
> 256),
> but only 83 vms
> turn out to run. When I run the 84th vm, engine says there is not
> enough memory. However at this time KSM is enabled and 15G free
> memory
> is still left on the host.
> 
> I checked the code and found out that before running a vm, the
> function hasMemoryToRunVM() in RunVmCommandBase would decide whether
> there is enough memory in the selected host to run it.
> The Algorithm in the function is like this:
> mem_avaliable >= mem_required = curVds.getmem_commited() +
> curVds.getpending_vmem_size()
>      + curVds.getguest_overhead() + curVds.getreserved_mem() +
> vm.getMinAllocatedMem();
> 
> And here is my question: curVds.getmem_commited() is caculated from
> the memory of vm
> assigned by user. But when the host is running with KSM enabled, the
> actual memory of each
> running vm would be smaller than the memory the user assigned to. In
> this case, the following
> may occur: engine says there be no more memroy to run any vm while
> the
> host has much free
> space to run more vms(in my case, 15G).
> 
> 
> Therefore I think the actual memory size reported by vdsm(The KSM
> shared memory) should be taken into account when calculating
> curVds.getmem_commited(). Any ideas are welcome.

Hi Ly,
Sorry for the delay. I'd like to look into this issue.
In the meanwhile a few relevant points;

1. You're saying that reserved_mem=256. This is not accurate, since it's
reported by vds as host_mem_reserve(256) + extra_mem_reserve(65) = 321

2. I'm assuming you retried running the 84th vm, just to make sure your
pending_vmem_size is 0 once all 83 VMs are running.

3. So assuming (2) is correct, I'd like to ask what's the max_vds_memory_over_commit
you have for the cluster? By default it's set to 120, and in such a case the 84th
VM should still be running.

Here's a calculation sample based on your data, and the above 3 issues:

vdsCurrentMem =
83 * (512M+65) = 47,891
0
65
321
1
=======
48,278

vdsMemLimit = 
120/100
*
47,321.1328125  // reported by vdsm: 'cat /proc/meminfo | grep MemTotal' / 1024
=========
56,785.359375

So vdsCurrentMem <= vdsMemLimit should be true unless you changed something
such as the MemTotal or the memory_over_commit. You can try and change memory_over_commit
let us know how it works.

Doron


From lpeer at redhat.com  Wed Oct 24 13:24:56 2012
From: lpeer at redhat.com (Livnat Peer)
Date: Wed, 24 Oct 2012 09:24:56 -0400 (EDT)
Subject: [Engine-devel] Cancelled: ovirt network
Message-ID: <1793088989.1266477.1351085096194.JavaMail.root@redhat.com>

A single instance of the following meeting has been cancelled:

Subject: ovirt network  
Organiser: "Livnat Peer" <lpeer at redhat.com> 

Time: Wednesday, 24 October, 2012, 4:00:00 PM - 5:00:00 PM GMT +02:00 Jerusalem
 
Invitees: engine-devel at ovirt.org; vdsm-devel at lists.fedorahosted.org; GARGYA at de.ibm.com; dyasny at redhat.com; simon at redhat.com; mkolesni at redhat.com; atal at redhat.com; ilvovsky at redhat.com; dfediuck at redhat.com; pradipta.banerjee at gmail.com; gkotton at redhat.com ... 


*~*~*~*~*~*~*~*~*~*

Hi All,
Due to day-light saving change in Israel this meeting collides with ovirt sync meeting this week.

I am cancelling this instance of the meeting, If there is a specific items you'd like to discuss related to networking please reply and we'll schedule a dedicated meeting.

Thanks, Livant
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20121024/2c65a38f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: meeting.ics
Type: text/calendar
Size: 4285 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20121024/2c65a38f/attachment.ics>

From vszocs at redhat.com  Wed Oct 24 17:34:23 2012
From: vszocs at redhat.com (Vojtech Szocs)
Date: Wed, 24 Oct 2012 13:34:23 -0400 (EDT)
Subject: [Engine-devel] UI Plugins: PoC patch revision 6 now available
In-Reply-To: <D290AD8432118048947689BA3AE8A9B3EA0742@SACEXCMBX04-PRD.hq.netapp.com>
Message-ID: <1821804266.11959773.1351100063623.JavaMail.root@redhat.com>

Hi Chris, 

no problem, I'll take care of implementing the dialog-related API function, with initial implementation using a native browser pop-up window (we can improve it later on, using WebAdmin dialog UI infrastructure). 

Since I'm currently preparing for my talk at oVirt Workshop (Barcelona), I'll have more time to work on UI plugins when I return back. In order to have revision 7 as soon as possible, I suggest to implement all planned items, except for "add custom sub tab", as part of revision 7. What do you think? 


Regards, 
Vojtech 

----- Original Message -----

From: "Christopher Morrissey" <Christopher.Morrissey at netapp.com> 
To: "Vojtech Szocs" <vszocs at redhat.com> 
Cc: "engine-devel" <engine-devel at ovirt.org> 
Sent: Tuesday, October 23, 2012 9:36:27 PM 
Subject: RE: [Engine-devel] UI Plugins: PoC patch revision 6 now available 



Hi Vojtech, 

It looks like I?m going to be in training all next week and will unfortunately NOT be able to take on the work to implement the ?show dialog with content loaded from given URL? plugin API function as I had hoped. This is something we really need for revision 7. Of the items in your list for inclusion, the sub-tab frame plugin is the least necessary for us. The rest of the items are all pretty important. 

Let me know if any of this is a problem or if we can shift things around to get them in the right order. 


-Chris 



From: Vojtech Szocs [mailto:vszocs at redhat.com] 
Sent: Tuesday, October 23, 2012 1:35 PM 
To: Morrissey, Christopher 
Cc: engine-devel 
Subject: Re: [Engine-devel] UI Plugins: PoC patch revision 6 now available 


Hi Chris, 

well, I planned to implement simple "show dialog with content loaded from given URL" plugin API function some time ago, but then I thought you might be experimenting with it already :) please feel free to work on that, we can include it into PoC revision 7. 

Regarding planned items for revision 7, here's my current list (feel free to add/modify things here if necessary): 

    * "add custom sub tab" plugin API function, with initial sub tab implementation showing content of the given URL (we can add more tab types later on, e.g. form-based or table-based tab) 
    * "add custom task to task pane" plugin API function, requires some UiCommon integration coding (I will handle this) 
    * "show dialog with content loaded from given URL" plugin API function, initial implementation could simply open new browser popup window using window.open (but any other approach is fine as well) 
    * integration with REST API, e.g. "obtain REST API authentication token" plugin API function, maybe also some API for performing actual HTTP REST calls? 


As for the Engine REST API authentication token, need to learn more about it, as WebAdmin GUI currently uses GWT RPC instead of REST API when communicating with the backend. 

You also mentioned that "we can make calls from our server into the REST API" - I assume this will be used together with "custom content for tab/dialog" plugin API functionality? (Otherwise I'd say the UI Plugin itself could make REST API calls on its own..) 

Regards, 
Vojtech 

----- Original Message -----


From: "Christopher Morrissey" <Christopher.Morrissey at netapp.com> 
To: "Vojtech Szocs" <vszocs at redhat.com>, "engine-devel" <engine-devel at ovirt.org> 
Sent: Monday, October 22, 2012 5:25:53 PM 
Subject: RE: [Engine-devel] UI Plugins: PoC patch revision 6 now available 
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. 


-Chris 



From: engine-devel-bounces at ovirt.org [mailto:engine-devel-bounces at 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 <OVIRT_HOME>/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, but this isn't relevant in our case). 

In contrast with traditional class-based object-oriented languages, JavaScript supports OOP through prototype-based programming model ( https://developer.mozilla.org/en-US/docs/JavaScript/Introduction_to_Object-Oriented_JavaScript ). At the same time, JavaScript language is dynamically-typed and therefore doesn't support traditional concept of interface in OOP, it uses "duck typing" technique instead ( http://en.wikipedia.org/wiki/Duck_typing ). 

The simplest way to provide an object that "implements the given interface" in JavaScript is to use "duck typing" technique: providing an object that contains well-known functions. In UI plugin infrastructure, I call this concept "interface object", represented by org.ovirt.engine.ui.webadmin.plugin.jsni.JsInterfaceObject class. Unlike the traditional concept of interface abstract type in object-oriented languages, an "interface object" does not necessarily have to declare all functions of the given interface in order to "implement" such interface. In fact, an empty object can be used as a valid "interface object". Missing functions will be simply treated as empty (no-op) functions. Furthermore, an "interface object" can "implement" multiple interfaces by declaring functions of those interfaces (interface composition). 

Getting back to "addMainTabActionButton" API, here's a sample code that adds new button to "Host" main tab data grid, as part of UiInit event handler function: 

UiInit: function () { 
api. addMainTabActionButton ('Host', 'Single-Host Action', 

// Action button interface object 
// All functions receive currently selected item(s) as function arguments 
{ 

// Called when the user clicks the button 
onClick : function () { 
// Calling 'arguments[0]' is safe, because onClick() can be called 
// only when exactly one item is currently selected in the data grid 
window.alert('Selected host entity ID = ' + arguments[0].entityId); 
}, 

// Returning 'true' means the button is enabled (clickable) 
// Returning 'false' means the button is disabled (non-clickable) 
// Default value = 'true' 
isEnabled : function () { 
// Enable button only when exactly one item is selected 
return arguments.length == 1; 
}, 

// Returning 'true' means the button is visible 
// Returning 'false' means the button is hidden 
// Default value = 'true' 
isAccessible : function () { 
// Always show the button in the corresponding data grid 
return true ; 
} 

} 

); 
} 

As mentioned above, all functions of an interface object are optional. For functions expecting return value, default value is defined by UI plugin infrastructure. For example: 

    * onClick - no default value (no return value expected) 
    * isEnabled / isAccessible - default value "true" (boolean return value expected) 

Note: UI plugin infrastructure checks the actual return value type, and uses default value in case the function returned something of wrong (unexpected) type. 

In the example above, "currently selected item(s)" maps to JSON-like representations of business entities currently selected in the corresponding data grid. For now, the entity representation is quite simple and same for all entity types: 

{ entityId: "[BusinessEntityGuidAsString]" } 

In future, we will create specific JSON-like representations for specific business entities, in compliance with Engine REST API entity structure. 

For a more extensive example of using "addMainTabActionButton" API, please see the attached "addMainTabActionButton.html.example" file. 



2. Improved plugin API function: addMainTab 

The "addMainTab" API was improved to address following issues: 

    * "addMainTab" can now be called at any moment during UI plugin runtime, given that the plugin is allowed invoke plugin API functions (plugin is either INITIALIZING or IN_USE). Previously, "addMainTab" worked reliably only when called from within UiInit event handler function. Currently, it's possible to call "addMainTab" at any moment, e.g. from within some other event handler function (after UiInit has completed). 


    * "addMainTab" now retains "active" tab (highlighted tab GUI). "addMainTab" works by adding new tab component (GWTP presenter proxy) and refreshing main tab panel GUI by removing all related tabs and re-adding them again. This logic is handled by org.ovirt.engine.ui.common.presenter.DynamicTabContainerPresenter class, which makes sure that "active" tab is retained even after main tab panel was refreshed. 

Furthermore, custom main tab implementation now displays the content of the given URL through HTML iframe element. 



3. Improved native JavaScript function handling (GWT JSNI) 

This patch introduces org.ovirt.engine.ui.webadmin.plugin.jsni.JsFunction and org.ovirt.engine.ui.webadmin.plugin.jsni.JsFunctionResultHelper classes providing Java abstraction for invoking native JavaScript functions. These classes follow the general contract of "interface object" as mentioned above. 

JsFunctionResultHelper is particularly useful when dealing with functions which are expected to return value of a certain type. Too bad standard GWT JSNI classes don't provide such abstraction for working with native functions out-of-the-box... 



4. ActionPanel and ActionTable type hierarchy refactoring (related to "addMainTabActionButton" API) 

Previously, AbstractActionPanel and AbstractActionTable classes didn't implement any reasonable interface that would allow other components (client-side UI plugin infrastructure) to depend on their functionality in a loosely-coupled manner. This would make code that implements "addMainTabActionButton" API "ugly": main tab view interface would have to reference AbstractActionTable class directly. In MVP design pattern, view interface should avoid referencing specific GWT Widget classes directly. 

This patch introduces new interfaces for ActionPanel and ActionTable components while eliminating code redundancy (duplicate or unnecessary code). 



5. ActionPanel type hierarchy refactoring (related to "addMainTab" API) 

Since org.ovirt.engine.ui.common.presenter.DynamicTabContainerPresenter defines new DynamicTabPanel interface that extends standard GWTP TabPanel interface, some refactoring had to be done in related ActionPanel classes. 

This patch makes sure that both org.ovirt.engine.ui.common.widget.tab.AbstractTabPanel (widget) and org.ovirt.engine.ui.common.view.AbstractTabPanelView (view) support DynamicTabPanel interface. 

Note that for now, only main tab panel (org.ovirt.engine.ui.webadmin.section.main.presenter.MainTabPanelPresenter) supports dynamic tabs within its view. 



Where is addSubTab API function? 

Implementing "addSubTab" API requires some more changes, and I didn't want to delay this PoC patch just because of it... 

Here's a sample code that illustrates proposed "addSubTab" API usage: 

UiInit: function () { 
api. addSubTab ('Host', // entityTypeName 
'Custom Host Sub Tab', // label 
'custom-host-sub-tab', // historyToken 
'http://www.ovirt.org/', // contentUrl 

// Sub tab interface object 
// All functions receive currently selected item(s) 
// within the main tab data grid as function arguments 
{ 

// Returning 'true' means the sub tab is visible 
// Returning 'false' means the sub tab is hidden 
// Default value = 'true' 
isAccessible : function () { 
return arguments.length == 1 && arguments[0].entityId == '<MyHostEntityId>'; 
} 

} 

); 
} 

As part of "addSubTab" API implementation, I'll refactor custom main tab components, in order to use one "tab type" for both main and sub tabs. 

Currently, we have one (and only one) "tab type" - a tab that shows content of the given URL through HTML iframe element. 

We could also create new "tab types", e.g. form-based tab that shows key/value pairs (IMHO this could be quite useful for custom sub tabs). 



Let me know what you think! 

Cheers, 
Vojtech 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20121024/45efa2e9/attachment.html>

From Christopher.Morrissey at netapp.com  Wed Oct 24 18:14:48 2012
From: Christopher.Morrissey at netapp.com (Morrissey, Christopher)
Date: Wed, 24 Oct 2012 18:14:48 +0000
Subject: [Engine-devel] UI Plugins: PoC patch revision 6 now available
In-Reply-To: <1821804266.11959773.1351100063623.JavaMail.root@redhat.com>
References: <D290AD8432118048947689BA3AE8A9B3EA0742@SACEXCMBX04-PRD.hq.netapp.com>
	<1821804266.11959773.1351100063623.JavaMail.root@redhat.com>
Message-ID: <D290AD8432118048947689BA3AE8A9B3EA0AD1@SACEXCMBX04-PRD.hq.netapp.com>

Hi Vojtech,

Thanks! That works for us. One last question. Any idea on when rev 7 will be available? ?

-Chris

From: Vojtech Szocs [mailto:vszocs at redhat.com]
Sent: Wednesday, October 24, 2012 1:34 PM
To: Morrissey, Christopher
Cc: engine-devel
Subject: Re: [Engine-devel] UI Plugins: PoC patch revision 6 now available

Hi Chris,

no problem, I'll take care of implementing the dialog-related API function, with initial implementation using a native browser pop-up window (we can improve it later on, using WebAdmin dialog UI infrastructure).

Since I'm currently preparing for my talk at oVirt Workshop (Barcelona), I'll have more time to work on UI plugins when I return back. In order to have revision 7 as soon as possible, I suggest to implement all planned items, except for "add custom sub tab", as part of revision 7. What do you think?

Regards,

Vojtech

________________________________
From: "Christopher Morrissey" <Christopher.Morrissey at netapp.com>
To: "Vojtech Szocs" <vszocs at redhat.com>
Cc: "engine-devel" <engine-devel at ovirt.org>
Sent: Tuesday, October 23, 2012 9:36:27 PM
Subject: RE: [Engine-devel] UI Plugins: PoC patch revision 6 now available
Hi Vojtech,

It looks like I?m going to be in training all next week and will unfortunately NOT be able to take on the work to implement the ?show dialog with content loaded from given URL? plugin API function as I had hoped. This is something we really need for revision 7. Of the items in your list for inclusion, the sub-tab frame plugin is the least necessary for us. The rest of the items are all pretty important.

Let me know if any of this is a problem or if we can shift things around to get them in the right order.

-Chris

From: Vojtech Szocs [mailto:vszocs at redhat.com]
Sent: Tuesday, October 23, 2012 1:35 PM
To: Morrissey, Christopher
Cc: engine-devel
Subject: Re: [Engine-devel] UI Plugins: PoC patch revision 6 now available

Hi Chris,

well, I planned to implement simple "show dialog with content loaded from given URL" plugin API function some time ago, but then I thought you might be experimenting with it already :) please feel free to work on that, we can include it into PoC revision 7.

Regarding planned items for revision 7, here's my current list (feel free to add/modify things here if necessary):

  *   "add custom sub tab" plugin API function, with initial sub tab implementation showing content of the given URL (we can add more tab types later on, e.g. form-based or table-based tab)
  *   "add custom task to task pane" plugin API function, requires some UiCommon integration coding (I will handle this)
  *   "show dialog with content loaded from given URL" plugin API function, initial implementation could simply open new browser popup window using window.open (but any other approach is fine as well)
  *   integration with REST API, e.g. "obtain REST API authentication token" plugin API function, maybe also some API for performing actual HTTP REST calls?



As for the Engine REST API authentication token, need to learn more about it, as WebAdmin GUI currently uses GWT RPC instead of REST API when communicating with the backend.



You also mentioned that "we can make calls from our server into the REST API" - I assume this will be used together with "custom content for tab/dialog" plugin API functionality? (Otherwise I'd say the UI Plugin itself could make REST API calls on its own..)



Regards,

Vojtech

________________________________
From: "Christopher Morrissey" <Christopher.Morrissey at netapp.com>
To: "Vojtech Szocs" <vszocs at redhat.com>, "engine-devel" <engine-devel at ovirt.org>
Sent: Monday, October 22, 2012 5:25:53 PM
Subject: RE: [Engine-devel] UI Plugins: PoC patch revision 6 now available
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.

-Chris

From: engine-devel-bounces at ovirt.org [mailto:engine-devel-bounces at 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 <OVIRT_HOME>/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, but this isn't relevant in our case).

In contrast with traditional class-based object-oriented languages, JavaScript supports OOP through prototype-based programming model (https://developer.mozilla.org/en-US/docs/JavaScript/Introduction_to_Object-Oriented_JavaScript). At the same time, JavaScript language is dynamically-typed and therefore doesn't support traditional concept of interface in OOP, it uses "duck typing" technique instead (http://en.wikipedia.org/wiki/Duck_typing).

The simplest way to provide an object that "implements the given interface" in JavaScript is to use "duck typing" technique: providing an object that contains well-known functions. In UI plugin infrastructure, I call this concept "interface object", represented by org.ovirt.engine.ui.webadmin.plugin.jsni.JsInterfaceObject class. Unlike the traditional concept of interface abstract type in object-oriented languages, an "interface object" does not necessarily have to declare all functions of the given interface in order to "implement" such interface. In fact, an empty object can be used as a valid "interface object". Missing functions will be simply treated as empty (no-op) functions. Furthermore, an "interface object" can "implement" multiple interfaces by declaring functions of those interfaces (interface composition).

Getting back to "addMainTabActionButton" API, here's a sample code that adds new button to "Host" main tab data grid, as part of UiInit event handler function:

UiInit: function() {
    api.addMainTabActionButton('Host', 'Single-Host Action',

        // Action button interface object
        // All functions receive currently selected item(s) as function arguments
        {

            // Called when the user clicks the button
            onClick: function() {
                // Calling 'arguments[0]' is safe, because onClick() can be called
                // only when exactly one item is currently selected in the data grid
                window.alert('Selected host entity ID = ' + arguments[0].entityId);
            },

            // Returning 'true' means the button is enabled (clickable)
            // Returning 'false' means the button is disabled (non-clickable)
            // Default value = 'true'
            isEnabled: function() {
                // Enable button only when exactly one item is selected
                return arguments.length == 1;
            },

            // Returning 'true' means the button is visible
            // Returning 'false' means the button is hidden
            // Default value = 'true'
            isAccessible: function() {
                // Always show the button in the corresponding data grid
                return true;
            }

        }

    );
}

As mentioned above, all functions of an interface object are optional. For functions expecting return value, default value is defined by UI plugin infrastructure. For example:

  *   onClick - no default value (no return value expected)
  *   isEnabled / isAccessible - default value "true" (boolean return value expected)

Note: UI plugin infrastructure checks the actual return value type, and uses default value in case the function returned something of wrong (unexpected) type.

In the example above, "currently selected item(s)" maps to JSON-like representations of business entities currently selected in the corresponding data grid. For now, the entity representation is quite simple and same for all entity types:

{ entityId: "[BusinessEntityGuidAsString]" }

In future, we will create specific JSON-like representations for specific business entities, in compliance with Engine REST API entity structure.

For a more extensive example of using "addMainTabActionButton" API, please see the attached "addMainTabActionButton.html.example" file.
________________________________

2. Improved plugin API function: addMainTab

The "addMainTab" API was improved to address following issues:

  *   "addMainTab" can now be called at any moment during UI plugin runtime, given that the plugin is allowed invoke plugin API functions (plugin is either INITIALIZING or IN_USE).
Previously, "addMainTab" worked reliably only when called from within UiInit event handler function.
Currently, it's possible to call "addMainTab" at any moment, e.g. from within some other event handler function (after UiInit has completed).

  *   "addMainTab" now retains "active" tab (highlighted tab GUI).
"addMainTab" works by adding new tab component (GWTP presenter proxy) and refreshing main tab panel GUI by removing all related tabs and re-adding them again.
This logic is handled by org.ovirt.engine.ui.common.presenter.DynamicTabContainerPresenter class, which makes sure that "active" tab is retained even after main tab panel was refreshed.
Furthermore, custom main tab implementation now displays the content of the given URL through HTML iframe element.
________________________________

3. Improved native JavaScript function handling (GWT JSNI)

This patch introduces org.ovirt.engine.ui.webadmin.plugin.jsni.JsFunction and org.ovirt.engine.ui.webadmin.plugin.jsni.JsFunctionResultHelper classes providing Java abstraction for invoking native JavaScript functions. These classes follow the general contract of "interface object" as mentioned above.

JsFunctionResultHelper is particularly useful when dealing with functions which are expected to return value of a certain type. Too bad standard GWT JSNI classes don't provide such abstraction for working with native functions out-of-the-box...
________________________________

4. ActionPanel and ActionTable type hierarchy refactoring (related to "addMainTabActionButton" API)

Previously, AbstractActionPanel and AbstractActionTable classes didn't implement any reasonable interface that would allow other components (client-side UI plugin infrastructure) to depend on their functionality in a loosely-coupled manner. This would make code that implements "addMainTabActionButton" API "ugly": main tab view interface would have to reference AbstractActionTable class directly. In MVP design pattern, view interface should avoid referencing specific GWT Widget classes directly.

This patch introduces new interfaces for ActionPanel and ActionTable components while eliminating code redundancy (duplicate or unnecessary code).
________________________________

5. ActionPanel type hierarchy refactoring (related to "addMainTab" API)

Since org.ovirt.engine.ui.common.presenter.DynamicTabContainerPresenter defines new DynamicTabPanel interface that extends standard GWTP TabPanel interface, some refactoring had to be done in related ActionPanel classes.

This patch makes sure that both org.ovirt.engine.ui.common.widget.tab.AbstractTabPanel (widget) and org.ovirt.engine.ui.common.view.AbstractTabPanelView (view) support DynamicTabPanel interface.

Note that for now, only main tab panel (org.ovirt.engine.ui.webadmin.section.main.presenter.MainTabPanelPresenter) supports dynamic tabs within its view.
________________________________

Where is addSubTab API function?

Implementing "addSubTab" API requires some more changes, and I didn't want to delay this PoC patch just because of it...

Here's a sample code that illustrates proposed "addSubTab" API usage:

UiInit: function() {
    api.addSubTab('Host',        // entityTypeName
        'Custom Host Sub Tab',   // label
        'custom-host-sub-tab',   // historyToken
        'http://www.ovirt.org/', // contentUrl

        // Sub tab interface object
        // All functions receive currently selected item(s)
        // within the main tab data grid as function arguments
        {

            // Returning 'true' means the sub tab is visible
            // Returning 'false' means the sub tab is hidden
            // Default value = 'true'
            isAccessible: function() {
                return arguments.length == 1 && arguments[0].entityId == '<MyHostEntityId>';
            }

        }

    );
}

As part of "addSubTab" API implementation, I'll refactor custom main tab components, in order to use one "tab type" for both main and sub tabs.

Currently, we have one (and only one) "tab type" - a tab that shows content of the given URL through HTML iframe element.

We could also create new "tab types", e.g. form-based tab that shows key/value pairs (IMHO this could be quite useful for custom sub tabs).
________________________________

Let me know what you think!

Cheers,
Vojtech


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20121024/5bad3457/attachment.html>

From vszocs at redhat.com  Wed Oct 24 18:24:16 2012
From: vszocs at redhat.com (Vojtech Szocs)
Date: Wed, 24 Oct 2012 14:24:16 -0400 (EDT)
Subject: [Engine-devel] UI Plugins: PoC patch revision 6 now available
In-Reply-To: <1094781798.24217819.1351068410177.JavaMail.root@redhat.com>
Message-ID: <1256928317.11974615.1351103056619.JavaMail.root@redhat.com>

Hi Oved,

thanks for sharing details on REST API session support! With this feature implemented, we could extend WebAdmin UI login procedure with REST API login, retrieving session ID from the cookie and providing it to UI plugins through the plugin API. We could also perform REST API logout upon WebAdmin UI logout. I see that [http://wiki.ovirt.org/wiki/Features/RESTSessionManagement] is currently in design phase, is it close to being implemented or will it take some more time to be available?

Alternatively, (without REST API session support) we could also do REST API login/logout as part of each REST API call; but since UI plugins might want to delegate the responsibility to make the actual REST API call to other (e.g. server-side) components, we'd have to expose WebAdmin UI login credentials to each plugin (I'm not sure if this is a good idea).

Regards,
Vojtech


----- Original Message -----
From: "Oved Ourfalli" <ovedo at redhat.com>
To: "Itamar Heim" <iheim at redhat.com>
Cc: "engine-devel" <engine-devel at ovirt.org>, "Christopher Morrissey" <Christopher.Morrissey at netapp.com>
Sent: Wednesday, October 24, 2012 10:46:50 AM
Subject: Re: [Engine-devel] UI Plugins: PoC patch revision 6 now available



----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Christopher Morrissey" <Christopher.Morrissey at netapp.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Tuesday, October 23, 2012 8:49:02 AM
> Subject: 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?
> 

Yes.
What we planned to do is different than the jasper reports solution.
We planned to take the same session ID that the webadmin has, and pass it over to the REST API as session ID (as we added the REST session support - http://wiki.ovirt.org/wiki/Features/RESTSessionManagement).

The problem is that while previous versions of jboss allowed using the same session in two different webapps, it is no longer possible in jboss AS7,
so what we would need to do is to login once to the REST API with the credentials as used in webadmin, get the session ID from the cookie, and save it for further requests.

> Thanks,
>     Itamar
> 
> >
> > -Chris
> >
> > *From:*engine-devel-bounces at ovirt.org
> > [mailto:engine-devel-bounces at 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 <OVIRT_HOME>/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, but this isn't relevant in our case).
> >
> > In contrast with traditional class-based object-oriented languages,
> > JavaScript supports OOP through prototype-based programming model
> > (https://developer.mozilla.org/en-US/docs/JavaScript/Introduction_to_Object-Oriented_JavaScript).
> > At the same time, JavaScript language is dynamically-typed and
> > therefore
> > doesn't support traditional concept of interface in OOP, it uses
> > "duck
> > typing" technique instead
> > (http://en.wikipedia.org/wiki/Duck_typing).
> >
> > The simplest way to provide an object that "implements the given
> > interface" in JavaScript is to use "duck typing" technique:
> > providing an
> > object that contains well-known functions. In UI plugin
> > infrastructure,
> > I call this concept "interface object", represented by
> > org.ovirt.engine.ui.webadmin.plugin.jsni.JsInterfaceObject class.
> > Unlike
> > the traditional concept of interface abstract type in
> > object-oriented
> > languages, an "interface object" _does not necessarily have to
> > declare
> > all functions of the given interface_ in order to "implement" such
> > interface. In fact, an empty object can be used as a valid
> > "interface
> > object". Missing functions will be simply treated as empty (no-op)
> > functions. Furthermore, an "interface object" can "implement"
> > multiple
> > interfaces by declaring functions of those interfaces (interface
> > composition).
> >
> > Getting back to "addMainTabActionButton" API, here's a sample code
> > that
> > adds new button to "Host" main tab data grid, as part of UiInit
> > event
> > handler function:
> >
> > UiInit: *function*() {
> >      api.addMainTabActionButton('Host', 'Single-Host Action',
> >
> >          // Action button interface object
> >          // All functions receive currently selected item(s) as
> >          function
> > arguments
> >          {
> >
> >              // Called when the user clicks the button
> > onClick: *function*() {
> >                  // Calling 'arguments[0]' is safe, because
> >                  onClick()
> > can be called
> >                  // only when exactly one item is currently
> >                  selected in
> > the data grid
> >                  window.alert('Selected host entity ID = ' +
> > arguments[0].entityId);
> >              },
> >
> >              // Returning 'true' means the button is enabled
> >              (clickable)
> >              // Returning 'false' means the button is disabled
> > (non-clickable)
> >              // Default value = 'true'
> > isEnabled: *function*() {
> >                  // Enable button only when exactly one item is
> >                  selected
> > *return*arguments.length == 1;
> >              },
> >
> >              // Returning 'true' means the button is visible
> >              // Returning 'false' means the button is hidden
> >              // Default value = 'true'
> > isAccessible: *function*() {
> >                  // Always show the button in the corresponding
> >                  data grid
> > *return**true*;
> >              }
> >
> >          }
> >
> >      );
> > }
> >
> > As mentioned above, all functions of an interface object are
> > optional.
> > For functions expecting return value, default value is defined by
> > UI
> > plugin infrastructure. For example:
> >
> >   * onClick - no default value (no return value expected)
> >   * isEnabled / isAccessible - default value "true" (boolean return
> >     value expected)
> >
> > Note: UI plugin infrastructure checks the actual return value type,
> > and
> > uses default value in case the function returned something of wrong
> > (unexpected) type.
> >
> >
> > In the example above, "currently selected item(s)" maps to
> > JSON-like
> > representations of business entities currently selected in the
> > corresponding data grid. For now, the entity representation is
> > quite
> > simple and same for all entity types:
> >
> > { entityId: "[BusinessEntityGuidAsString]" }
> >
> > In future, we will create specific JSON-like representations for
> > specific business entities, in compliance with Engine REST API
> > entity
> > structure.
> >
> > For a more extensive example of using "addMainTabActionButton" API,
> > please see the attached "addMainTabActionButton.html.example" file.
> >
> > ------------------------------------------------------------------------
> >
> >
> > *2. Improved plugin API function: addMainTab
> > *
> > The "addMainTab" API was improved to address following issues:
> >
> >   * "addMainTab" can now be called at any moment during UI plugin
> >     runtime, given that the plugin is allowed invoke plugin API
> >     functions (plugin is either INITIALIZING or IN_USE).
> >     Previously, "addMainTab" worked reliably only when called from
> >     within UiInit event handler function.
> >     Currently, it's possible to call "addMainTab" at any moment,
> >     e.g.
> >     from within some other event handler function (after UiInit has
> >     completed).
> >
> >   * "addMainTab" now retains "active" tab (highlighted tab GUI).
> >     "addMainTab" works by adding new tab component (GWTP presenter
> >     proxy) and refreshing main tab panel GUI by removing all
> >     related
> >     tabs and re-adding them again.
> >     This logic is handled by
> >     org.ovirt.engine.ui.common.presenter.DynamicTabContainerPresenter
> >     class, which makes sure that "active" tab is retained even
> >     after
> >     main tab panel was refreshed.
> >
> > Furthermore, custom main tab implementation now displays the
> > content of
> > the given URL through HTML iframe element.
> >
> > ------------------------------------------------------------------------
> >
> >
> > *3. Improved native JavaScript function handling* (GWT JSNI)
> >
> > This patch introduces
> > org.ovirt.engine.ui.webadmin.plugin.jsni.JsFunction and
> > org.ovirt.engine.ui.webadmin.plugin.jsni.JsFunctionResultHelper
> > classes
> > providing Java abstraction for invoking native JavaScript
> > functions.
> > These classes follow the general contract of "interface object" as
> > mentioned above.
> >
> > JsFunctionResultHelper is particularly useful when dealing with
> > functions which are expected to return value of a certain type. Too
> > bad
> > standard GWT JSNI classes don't provide such abstraction for
> > working
> > with native functions out-of-the-box...
> >
> > ------------------------------------------------------------------------
> >
> >
> > *4. ActionPanel and ActionTable type hierarchy refactoring*
> > (related to
> > "addMainTabActionButton" API)*
> > *
> > Previously, AbstractActionPanel and AbstractActionTable classes
> > didn't
> > implement any reasonable interface that would allow other
> > components
> > (client-side UI plugin infrastructure) to depend on their
> > functionality
> > in a loosely-coupled manner. This would make code that implements
> > "addMainTabActionButton" API "ugly": main tab view interface would
> > have
> > to reference AbstractActionTable class directly. In MVP design
> > pattern,
> > view interface should avoid referencing specific GWT Widget classes
> > directly.
> >
> > This patch introduces new interfaces for ActionPanel and
> > ActionTable
> > components while eliminating code redundancy (duplicate or
> > unnecessary
> > code).
> >
> > ------------------------------------------------------------------------
> >
> >
> > *5. ActionPanel type hierarchy refactoring* (related to
> > "addMainTab" API)
> >
> > Since
> > org.ovirt.engine.ui.common.presenter.DynamicTabContainerPresenter
> > defines new DynamicTabPanel interface that extends standard GWTP
> > TabPanel interface, some refactoring had to be done in related
> > ActionPanel classes.
> >
> > This patch makes sure that both
> > org.ovirt.engine.ui.common.widget.tab.AbstractTabPanel (widget) and
> > org.ovirt.engine.ui.common.view.AbstractTabPanelView (view) support
> > DynamicTabPanel interface.
> >
> > Note that for now, only main tab panel
> > (org.ovirt.engine.ui.webadmin.section.main.presenter.MainTabPanelPresenter)
> > supports dynamic tabs within its view.
> >
> > ------------------------------------------------------------------------
> >
> >
> > *Where is addSubTab API function?*
> >
> > Implementing "addSubTab" API requires some more changes, and I
> > didn't
> > want to delay this PoC patch just because of it...
> >
> > Here's a sample code that illustrates proposed "addSubTab" API
> > usage:
> >
> > UiInit: *function*() {
> >      api.addSubTab('Host', // entityTypeName
> >          'Custom Host Sub Tab', // label
> >          'custom-host-sub-tab', // historyToken
> >          'http://www.ovirt.org/', // contentUrl
> >
> > // Sub tab interface object
> >          // All functions receive currently selected item(s)
> >          // within the main tab data grid as function arguments
> >          {
> >
> >              // Returning 'true' means the sub tab is visible
> >              // Returning 'false' means the sub tab is hidden
> >              // Default value = 'true'
> > isAccessible: *function*() {
> > *return*arguments.length == 1 && arguments[0].entityId ==
> > '<MyHostEntityId>';
> >              }
> >
> >          }
> >
> >      );
> > }
> >
> > As part of "addSubTab" API implementation, I'll refactor custom
> > main tab
> > components, in order to use one "tab type" for both main and sub
> > tabs.
> >
> > Currently, we have one (and only one) "tab type" - a tab that shows
> > content of the given URL through HTML iframe element.
> >
> > We could also create new "tab types", e.g. form-based tab that
> > shows
> > key/value pairs (IMHO this could be quite useful for custom sub
> > tabs).
> >
> > ------------------------------------------------------------------------
> >
> >
> > Let me know what you think!
> >
> > Cheers,
> > Vojtech
> >
> >
> >
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
> 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
_______________________________________________
Engine-devel mailing list
Engine-devel at ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel


From vszocs at redhat.com  Wed Oct 24 18:33:34 2012
From: vszocs at redhat.com (Vojtech Szocs)
Date: Wed, 24 Oct 2012 14:33:34 -0400 (EDT)
Subject: [Engine-devel] UI Plugins: PoC patch revision 6 now available
In-Reply-To: <D290AD8432118048947689BA3AE8A9B3EA0AD1@SACEXCMBX04-PRD.hq.netapp.com>
Message-ID: <37113151.11978289.1351103614440.JavaMail.root@redhat.com>

Hi Chris, 

thanks for pointing that out, I forgot to mention the dates :) 

oVirt Workshop (Barcelona) ends on Nov 9 (Friday) so I'm planning to release UI plugins PoC revision 7 around Nov 15 (next week's Thursday). I'll try to work on some items before flying to Barcelona next week. 

Thanks, 
Vojtech 


----- Original Message -----

From: "Christopher Morrissey" <Christopher.Morrissey at netapp.com> 
To: "Vojtech Szocs" <vszocs at redhat.com> 
Cc: "engine-devel" <engine-devel at ovirt.org> 
Sent: Wednesday, October 24, 2012 8:14:48 PM 
Subject: RE: [Engine-devel] UI Plugins: PoC patch revision 6 now available 



Hi Vojtech, 

Thanks! That works for us. One last question. Any idea on when rev 7 will be available? J 


-Chris 



From: Vojtech Szocs [mailto:vszocs at redhat.com] 
Sent: Wednesday, October 24, 2012 1:34 PM 
To: Morrissey, Christopher 
Cc: engine-devel 
Subject: Re: [Engine-devel] UI Plugins: PoC patch revision 6 now available 


Hi Chris, 

no problem, I'll take care of implementing the dialog-related API function, with initial implementation using a native browser pop-up window (we can improve it later on, using WebAdmin dialog UI infrastructure). 

Since I'm currently preparing for my talk at oVirt Workshop (Barcelona), I'll have more time to work on UI plugins when I return back. In order to have revision 7 as soon as possible, I suggest to implement all planned items, except for "add custom sub tab", as part of revision 7. What do you think? 
Regards, 
Vojtech 

----- Original Message -----


From: "Christopher Morrissey" <Christopher.Morrissey at netapp.com> 
To: "Vojtech Szocs" <vszocs at redhat.com> 
Cc: "engine-devel" <engine-devel at ovirt.org> 
Sent: Tuesday, October 23, 2012 9:36:27 PM 
Subject: RE: [Engine-devel] UI Plugins: PoC patch revision 6 now available 
Hi Vojtech, 

It looks like I?m going to be in training all next week and will unfortunately NOT be able to take on the work to implement the ?show dialog with content loaded from given URL? plugin API function as I had hoped. This is something we really need for revision 7. Of the items in your list for inclusion, the sub-tab frame plugin is the least necessary for us. The rest of the items are all pretty important. 

Let me know if any of this is a problem or if we can shift things around to get them in the right order. 


-Chris 



From: Vojtech Szocs [mailto:vszocs at redhat.com] 
Sent: Tuesday, October 23, 2012 1:35 PM 
To: Morrissey, Christopher 
Cc: engine-devel 
Subject: Re: [Engine-devel] UI Plugins: PoC patch revision 6 now available 


Hi Chris, 

well, I planned to implement simple "show dialog with content loaded from given URL" plugin API function some time ago, but then I thought you might be experimenting with it already :) please feel free to work on that, we can include it into PoC revision 7. 

Regarding planned items for revision 7, here's my current list (feel free to add/modify things here if necessary): 

    * "add custom sub tab" plugin API function, with initial sub tab implementation showing content of the given URL (we can add more tab types later on, e.g. form-based or table-based tab) 
    * "add custom task to task pane" plugin API function, requires some UiCommon integration coding (I will handle this) 
    * "show dialog with content loaded from given URL" plugin API function, initial implementation could simply open new browser popup window using window.open (but any other approach is fine as well) 
    * integration with REST API, e.g. "obtain REST API authentication token" plugin API function, maybe also some API for performing actual HTTP REST calls? 


As for the Engine REST API authentication token, need to learn more about it, as WebAdmin GUI currently uses GWT RPC instead of REST API when communicating with the backend. 

You also mentioned that "we can make calls from our server into the REST API" - I assume this will be used together with "custom content for tab/dialog" plugin API functionality? (Otherwise I'd say the UI Plugin itself could make REST API calls on its own..) 

Regards, 
Vojtech 




From: "Christopher Morrissey" <Christopher.Morrissey at netapp.com> 
To: "Vojtech Szocs" <vszocs at redhat.com>, "engine-devel" <engine-devel at ovirt.org> 
Sent: Monday, October 22, 2012 5:25:53 PM 
Subject: RE: [Engine-devel] UI Plugins: PoC patch revision 6 now available 
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. 


-Chris 



From: engine-devel-bounces at ovirt.org [mailto:engine-devel-bounces at 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 <OVIRT_HOME>/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, but this isn't relevant in our case). 

In contrast with traditional class-based object-oriented languages, JavaScript supports OOP through prototype-based programming model ( https://developer.mozilla.org/en-US/docs/JavaScript/Introduction_to_Object-Oriented_JavaScript ). At the same time, JavaScript language is dynamically-typed and therefore doesn't support traditional concept of interface in OOP, it uses "duck typing" technique instead ( http://en.wikipedia.org/wiki/Duck_typing ). 

The simplest way to provide an object that "implements the given interface" in JavaScript is to use "duck typing" technique: providing an object that contains well-known functions. In UI plugin infrastructure, I call this concept "interface object", represented by org.ovirt.engine.ui.webadmin.plugin.jsni.JsInterfaceObject class. Unlike the traditional concept of interface abstract type in object-oriented languages, an "interface object" does not necessarily have to declare all functions of the given interface in order to "implement" such interface. In fact, an empty object can be used as a valid "interface object". Missing functions will be simply treated as empty (no-op) functions. Furthermore, an "interface object" can "implement" multiple interfaces by declaring functions of those interfaces (interface composition). 

Getting back to "addMainTabActionButton" API, here's a sample code that adds new button to "Host" main tab data grid, as part of UiInit event handler function: 

UiInit: function () { 
api. addMainTabActionButton ('Host', 'Single-Host Action', 

// Action button interface object 
// All functions receive currently selected item(s) as function arguments 
{ 

// Called when the user clicks the button 
onClick : function () { 
// Calling 'arguments[0]' is safe, because onClick() can be called 
// only when exactly one item is currently selected in the data grid 
window.alert('Selected host entity ID = ' + arguments[0].entityId); 
}, 

// Returning 'true' means the button is enabled (clickable) 
// Returning 'false' means the button is disabled (non-clickable) 
// Default value = 'true' 
isEnabled : function () { 
// Enable button only when exactly one item is selected 
return arguments.length == 1; 
}, 

// Returning 'true' means the button is visible 
// Returning 'false' means the button is hidden 
// Default value = 'true' 
isAccessible : function () { 
// Always show the button in the corresponding data grid 
return true ; 
} 

} 

); 
} 

As mentioned above, all functions of an interface object are optional. For functions expecting return value, default value is defined by UI plugin infrastructure. For example: 

    * onClick - no default value (no return value expected) 
    * isEnabled / isAccessible - default value "true" (boolean return value expected) 

Note: UI plugin infrastructure checks the actual return value type, and uses default value in case the function returned something of wrong (unexpected) type. 

In the example above, "currently selected item(s)" maps to JSON-like representations of business entities currently selected in the corresponding data grid. For now, the entity representation is quite simple and same for all entity types: 

{ entityId: "[BusinessEntityGuidAsString]" } 

In future, we will create specific JSON-like representations for specific business entities, in compliance with Engine REST API entity structure. 

For a more extensive example of using "addMainTabActionButton" API, please see the attached "addMainTabActionButton.html.example" file. 



2. Improved plugin API function: addMainTab 

The "addMainTab" API was improved to address following issues: 

    * "addMainTab" can now be called at any moment during UI plugin runtime, given that the plugin is allowed invoke plugin API functions (plugin is either INITIALIZING or IN_USE). Previously, "addMainTab" worked reliably only when called from within UiInit event handler function. Currently, it's possible to call "addMainTab" at any moment, e.g. from within some other event handler function (after UiInit has completed). 


    * "addMainTab" now retains "active" tab (highlighted tab GUI). "addMainTab" works by adding new tab component (GWTP presenter proxy) and refreshing main tab panel GUI by removing all related tabs and re-adding them again. This logic is handled by org.ovirt.engine.ui.common.presenter.DynamicTabContainerPresenter class, which makes sure that "active" tab is retained even after main tab panel was refreshed. 

Furthermore, custom main tab implementation now displays the content of the given URL through HTML iframe element. 



3. Improved native JavaScript function handling (GWT JSNI) 

This patch introduces org.ovirt.engine.ui.webadmin.plugin.jsni.JsFunction and org.ovirt.engine.ui.webadmin.plugin.jsni.JsFunctionResultHelper classes providing Java abstraction for invoking native JavaScript functions. These classes follow the general contract of "interface object" as mentioned above. 

JsFunctionResultHelper is particularly useful when dealing with functions which are expected to return value of a certain type. Too bad standard GWT JSNI classes don't provide such abstraction for working with native functions out-of-the-box... 



4. ActionPanel and ActionTable type hierarchy refactoring (related to "addMainTabActionButton" API) 

Previously, AbstractActionPanel and AbstractActionTable classes didn't implement any reasonable interface that would allow other components (client-side UI plugin infrastructure) to depend on their functionality in a loosely-coupled manner. This would make code that implements "addMainTabActionButton" API "ugly": main tab view interface would have to reference AbstractActionTable class directly. In MVP design pattern, view interface should avoid referencing specific GWT Widget classes directly. 

This patch introduces new interfaces for ActionPanel and ActionTable components while eliminating code redundancy (duplicate or unnecessary code). 



5. ActionPanel type hierarchy refactoring (related to "addMainTab" API) 

Since org.ovirt.engine.ui.common.presenter.DynamicTabContainerPresenter defines new DynamicTabPanel interface that extends standard GWTP TabPanel interface, some refactoring had to be done in related ActionPanel classes. 

This patch makes sure that both org.ovirt.engine.ui.common.widget.tab.AbstractTabPanel (widget) and org.ovirt.engine.ui.common.view.AbstractTabPanelView (view) support DynamicTabPanel interface. 

Note that for now, only main tab panel (org.ovirt.engine.ui.webadmin.section.main.presenter.MainTabPanelPresenter) supports dynamic tabs within its view. 



Where is addSubTab API function? 

Implementing "addSubTab" API requires some more changes, and I didn't want to delay this PoC patch just because of it... 

Here's a sample code that illustrates proposed "addSubTab" API usage: 

UiInit: function () { 
api. addSubTab ('Host', // entityTypeName 
'Custom Host Sub Tab', // label 
'custom-host-sub-tab', // historyToken 
'http://www.ovirt.org/', // contentUrl 

// Sub tab interface object 
// All functions receive currently selected item(s) 
// within the main tab data grid as function arguments 
{ 

// Returning 'true' means the sub tab is visible 
// Returning 'false' means the sub tab is hidden 
// Default value = 'true' 
isAccessible : function () { 
return arguments.length == 1 && arguments[0].entityId == '<MyHostEntityId>'; 
} 

} 

); 
} 

As part of "addSubTab" API implementation, I'll refactor custom main tab components, in order to use one "tab type" for both main and sub tabs. 

Currently, we have one (and only one) "tab type" - a tab that shows content of the given URL through HTML iframe element. 

We could also create new "tab types", e.g. form-based tab that shows key/value pairs (IMHO this could be quite useful for custom sub tabs). 



Let me know what you think! 

Cheers, 
Vojtech 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20121024/ac6f8098/attachment.html>

From ovedo at redhat.com  Wed Oct 24 20:09:45 2012
From: ovedo at redhat.com (Oved Ourfalli)
Date: Wed, 24 Oct 2012 16:09:45 -0400 (EDT)
Subject: [Engine-devel] UI Plugins: PoC patch revision 6 now available
In-Reply-To: <1256928317.11974615.1351103056619.JavaMail.root@redhat.com>
Message-ID: <2101891603.24772646.1351109385060.JavaMail.root@redhat.com>


----- Vojtech Szocs <vszocs at redhat.com> wrote:
> Hi Oved,
> 
> thanks for sharing details on REST API session support! With this feature implemented, we could extend WebAdmin UI login procedure with REST API login, retrieving session ID from the cookie and providing it to UI plugins through the plugin API. We could also perform REST API logout upon WebAdmin UI logout. I see that [http://wiki.ovirt.org/wiki/Features/RESTSessionManagement] is currently in design phase, is it close to being implemented or will it take some more time to be available?

It is already implemented and tested for a while now.  I'll update the wiki page accordingly. 

What you suggested was exactly what I had in mind. I'll catch you on irc tomorrow to discuss the details, and see if you need any help, but looks like that would work.

Regards,
Oved
> 
> Alternatively, (without REST API session support) we could also do REST API login/logout as part of each REST API call; but since UI plugins might want to delegate the responsibility to make the actual REST API call to other (e.g. server-side) components, we'd have to expose WebAdmin UI login credentials to each plugin (I'm not sure if this is a good idea).
> 
> Regards,
> Vojtech
> 
> 
> ----- Original Message -----
> From: "Oved Ourfalli" <ovedo at redhat.com>
> To: "Itamar Heim" <iheim at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>, "Christopher Morrissey" <Christopher.Morrissey at netapp.com>
> Sent: Wednesday, October 24, 2012 10:46:50 AM
> Subject: Re: [Engine-devel] UI Plugins: PoC patch revision 6 now available
> 
> 
> 
> ----- Original Message -----
> > From: "Itamar Heim" <iheim at redhat.com>
> > To: "Christopher Morrissey" <Christopher.Morrissey at netapp.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Tuesday, October 23, 2012 8:49:02 AM
> > Subject: 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?
> > 
> 
> Yes.
> What we planned to do is different than the jasper reports solution.
> We planned to take the same session ID that the webadmin has, and pass it over to the REST API as session ID (as we added the REST session support - http://wiki.ovirt.org/wiki/Features/RESTSessionManagement).
> 
> The problem is that while previous versions of jboss allowed using the same session in two different webapps, it is no longer possible in jboss AS7,
> so what we would need to do is to login once to the REST API with the credentials as used in webadmin, get the session ID from the cookie, and save it for further requests.
> 
> > Thanks,
> > Itamar
> > 
> > >
> > > -Chris
> > >
> > > *From:*engine-devel-bounces at ovirt.org
> > > [mailto:engine-devel-bounces at 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 <OVIRT_HOME>/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, but this isn't relevant in our case).
> > >
> > > In contrast with traditional class-based object-oriented languages,
> > > JavaScript supports OOP through prototype-based programming model
> > > (https://developer.mozilla.org/en-US/docs/JavaScript/Introduction_to_Object-Oriented_JavaScript).
> > > At the same time, JavaScript language is dynamically-typed and
> > > therefore
> > > doesn't support traditional concept of interface in OOP, it uses
> > > "duck
> > > typing" technique instead
> > > (http://en.wikipedia.org/wiki/Duck_typing).
> > >
> > > The simplest way to provide an object that "implements the given
> > > interface" in JavaScript is to use "duck typing" technique:
> > > providing an
> > > object that contains well-known functions. In UI plugin
> > > infrastructure,
> > > I call this concept "interface object", represented by
> > > org.ovirt.engine.ui.webadmin.plugin.jsni.JsInterfaceObject class.
> > > Unlike
> > > the traditional concept of interface abstract type in
> > > object-oriented
> > > languages, an "interface object" _does not necessarily have to
> > > declare
> > > all functions of the given interface_ in order to "implement" such
> > > interface. In fact, an empty object can be used as a valid
> > > "interface
> > > object". Missing functions will be simply treated as empty (no-op)
> > > functions. Furthermore, an "interface object" can "implement"
> > > multiple
> > > interfaces by declaring functions of those interfaces (interface
> > > composition).
> > >
> > > Getting back to "addMainTabActionButton" API, here's a sample code
> > > that
> > > adds new button to "Host" main tab data grid, as part of UiInit
> > > event
> > > handler function:
> > >
> > > UiInit: *function*() {
> > > api.addMainTabActionButton('Host', 'Single-Host Action',
> > >
> > > // Action button interface object
> > > // All functions receive currently selected item(s) as
> > > function
> > > arguments
> > > {
> > >
> > > // Called when the user clicks the button
> > > onClick: *function*() {
> > > // Calling 'arguments[0]' is safe, because
> > > onClick()
> > > can be called
> > > // only when exactly one item is currently
> > > selected in
> > > the data grid
> > > window.alert('Selected host entity ID = ' +
> > > arguments[0].entityId);
> > > },
> > >
> > > // Returning 'true' means the button is enabled
> > > (clickable)
> > > // Returning 'false' means the button is disabled
> > > (non-clickable)
> > > // Default value = 'true'
> > > isEnabled: *function*() {
> > > // Enable button only when exactly one item is
> > > selected
> > > *return*arguments.length == 1;
> > > },
> > >
> > > // Returning 'true' means the button is visible
> > > // Returning 'false' means the button is hidden
> > > // Default value = 'true'
> > > isAccessible: *function*() {
> > > // Always show the button in the corresponding
> > > data grid
> > > *return**true*;
> > > }
> > >
> > > }
> > >
> > > );
> > > }
> > >
> > > As mentioned above, all functions of an interface object are
> > > optional.
> > > For functions expecting return value, default value is defined by
> > > UI
> > > plugin infrastructure. For example:
> > >
> > > * onClick - no default value (no return value expected)
> > > * isEnabled / isAccessible - default value "true" (boolean return
> > > value expected)
> > >
> > > Note: UI plugin infrastructure checks the actual return value type,
> >rently
> > > uses default value in case the function returned something of wrong
> > > (unexpected) type.
> > >
> > >
> > > In the example above, "currently selected item(s)" maps to
> > > JSON-like
> > > representations of business entities currently selected in the
> > > corresponding data grid. For now, the entity representation is
> > > quite
> > > simple and same for all entity types:
> > >
> > > { entityId: "[BusinessEntityGuidAsString]" }
> > >
> > > In future, we will create specific JSON-like representations for
> > > specific business entities, in compliance with Engine REST API
> > > entity
> > > structure.
> > >
> > > For a more extensive example of using "addMainTabActionButton" API,
> > > please see the attached "addMainTabActionButton.html.example" file.
> > >
> > > ------------------------------------------------------------------------
> > >
> > >
> > > *2. Improved plugin API function: addMainTab
> > > *
> > > The "addMainTab" API was improved to address following issues:
> > >
> > > * "addMainTab" can now be called at any moment during UI plugin
> > > runtime, given that the plugin is allowed invoke plugin API
> > > functions (plugin is either INITIALIZING or IN_USE).
> > > Previously, "addMainTab" worked reliably only when called from
> > > within UiInit event handler function.
> > > Currently, it's possible to call "addMainTab" at any moment,
> > > e.g.
> > > from within some other event handler function (after UiInit has
> > > completed).
> > >
> > > * "addMainTab" now retains "active" tab (highlighted tab GUI).
> > > "addMainTab" works by adding new tab component (GWTP presenter
> > > proxy) and refreshing main tab panel GUI by removing all
> > > related
> > > tabs and re-adding them again.
> > > This logic is handled by
> > > org.ovirt.engine.ui.common.presenter.DynamicTabContainerPresenter
> > > class, which makes sure that "active" tab is retained even
> > > after
> > > main tab panel was refreshed.
> > >
> > > Furthermore, custom main tab implementation now displays the
> > > content of
> > > the given URL through HTML iframe element.
> > >
> > > ------------------------------------------------------------------------
> > >
> > >
> > > *3. Improved native JavaScript function handling* (GWT JSNI)
> > >
> > > This patch introduces
> > > org.ovirt.engine.ui.webadmin.plugin.jsni.JsFunction and
> > > org.ovirt.engine.ui.webadmin.plugin.jsni.JsFunctionResultHelper
> > > classes
> > > providing Java abstraction for invoking native JavaScript
> > > functions.
> > > These classes follow the general contract of "interface object" as
> > > mentioned above.
> > >
> > > JsFunctionResultHelper is particularly useful when dealing with
> > > functions which are expected to return value of a certain type. Too
> > > bad
> > > standard GWT JSNI classes don't provide such abstraction for
> > > working
> > > with native functions out-of-the-box...
> > >
> > > ------------------------------------------------------------------------
> > >
> > >
> > > *4. ActionPanel and ActionTable type hierarchy refactoring*
> > > (related to
> > > "addMainTabActionButton" API)*
> > > *
> > > Previously, AbstractActionPanel and AbstractActionTable classes
> > > didn't
> > > implement any reasonable interface that would allow other
> > > components
> > > (client-side UI plugin infrastructure) to depend on their
> > > functionality
> > > in a loosely-coupled manner. This would make code that implements
> > > "addMainTabActionButton" API "ugly": main tab view interface would
> > > have
> > > to reference AbstractActionTable class directly. In MVP design
> > > pattern,
> > > view interface should avoid referencing specific GWT Widget classes
> > > directly.
> > >
> > > This patch introduces new interfaces for ActionPanel and
> > > ActionTable
> > > components while eliminating code redundancy (duplicate or
> > > unnecessary
> > > code).
> > >
> > > ------------------------------------------------------------------------
> > >
> > >
> > > *5. ActionPanel type hierarchy refactoring* (related to
> > > "addMainTab" API)
> > >
> > > Since
> > > org.ovirt.engine.ui.common.presenter.DynamicTabContainerPresenter
> > > defines new DynamicTabPanel interface that extends standard GWTP
> > > TabPanel interface, some refactoring had to be done in related
> > > ActionPanel classes.
> > >
> > > This patch makes sure that both
> > > org.ovirt.engine.ui.common.widget.tab.AbstractTabPanel (widget) and
> > > org.ovirt.engine.ui.common.view.AbstractTabPanelView (view) support
> > > DynamicTabPanel interface.
> > >
> > > Note that for now, only main tab panel
> > > (org.ovirt.engine.ui.webadmin.section.main.presenter.MainTabPanelPresenter)
> > > supports dynamic tabs within its view.
> > >
> > > ------------------------------------------------------------------------
> > >
> > >
> > > *Where is addSubTab API function?*
> > >
> > > Implementing "addSubTab" API requires some more changes, and I
> > > didn't
> > > want to delay this PoC patch just because of it...
> > >
> > > Here's a sample code that illustrates proposed "addSubTab" API
> > > usage:
> > >
> > > UiInit: *function*() {
> > > api.addSubTab('Host', // entityTypeName
> > > 'Custom Host Sub Tab', // label
> > > 'custom-host-sub-tab', // historyToken
> > > 'http://www.ovirt.org/', // contentUrl
> > >
> > > // Sub tab interface object
> > > // All functions receive currently selected item(s)
> > > // within the main tab data grid as function arguments
> > > {
> > >
> > > // Returning 'true' means the sub tab is visible
> > > // Returning 'false' means the sub tab is hidden
> > > // Default value = 'true'
> > > isAccessible: *function*() {
> > > *return*arguments.length == 1 && arguments[0].entityId ==
> > > '<MyHostEntityId>';
> > > }
> > >
> > > }
> > >
> > > );
> > > }
> > >
> > > As part of "addSubTab" API implementation, I'll refactor custom
> > > main tab
> > > components, in order to use one "tab type" for both main and sub
> > > tabs.
> > >
> > > Currently, we have one (and only one) "tab type" - a tab that shows
> > > content of the given URL through HTML iframe element.
> > >
> > > We could also create new "tab types", e.g. form-based tab that
> > > shows
> > > key/value pairs (IMHO this could be quite useful for custom sub
> > > tabs).
> > >
> > > ------------------------------------------------------------------------
> > >
> > >
> > > Let me know what you think!
> > >
> > > Cheers,
> > > Vojtech
> > >
> > >
> > >
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > >
> > 
> > 
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel



From medievalist at gmail.com  Wed Oct 24 21:36:40 2012
From: medievalist at gmail.com (Charlie)
Date: Wed, 24 Oct 2012 17:36:40 -0400
Subject: [Engine-devel] alias in disk instead of name
In-Reply-To: <1952920135.5438345.1351067060563.JavaMail.root@redhat.com>
References: <50876831.1030309@redhat.com>
	<1952920135.5438345.1351067060563.JavaMail.root@redhat.com>
Message-ID: <CAJb3uA4XgSeDWuUvns8z6nrp7wUmJjw=4vGqfErWBUwzQ-QUmw@mail.gmail.com>

Makes sense to me, in the context of the concerns you raised earlier.
I did not suggest prepending vm name because I was not absolutely sure
it was guaranteed unique (I'm lurking here to learn these things).

--C

On Wed, Oct 24, 2012 at 4:24 AM, Simon Grinberg <simon at redhat.com> wrote:
>
>
> ----- Original Message -----
>> From: "Itamar Heim" <iheim at redhat.com>
>> To: "Simon Grinberg" <simon at redhat.com>
>> Cc: "Ewoud Kohl van Wijngaarden" <ewoud at kohlvanwijngaarden.nl>, "engine-devel" <engine-devel at ovirt.org>
>> Sent: Wednesday, October 24, 2012 6:01:53 AM
>> Subject: Re: [Engine-devel] alias in disk instead of name
>>
>> On 10/23/2012 08:07 PM, Simon Grinberg wrote:
>> >
>> >
>> > ----- Original Message -----
>> >> From: "Charlie" <medievalist at gmail.com>
>> >> To: "Simon Grinberg" <simon at redhat.com>
>> >> Cc: "engine-devel" <engine-devel at ovirt.org>
>> >> Sent: Tuesday, October 23, 2012 7:53:10 PM
>> >> Subject: Re: [Engine-devel] alias in disk instead of name
>> >>
>> >> Why not something like this?
>> >>
>> >> (pseudocode, using dot for string concatenation):
>> >>
>> >> $name_prefix = "vmdrive"
>> >> $name = get_last_used($name_prefix)
>> >> $already_in_use = $TRUE
>> >>
>> >> while $already_in_use {
>> >>       prompt "Name of thing? [$name] ", $name
>> >>       if name_used($name) {
>> >>           while name_used($name) {
>> >>              increment_number($name)
>> >>           }
>> >>       } else {
>> >>           $already_in_use = FALSE
>> >>       }
>> >> }
>> >>
>> >> do_whatever_you_do_with($name)
>> >>
>> >> store_last_used($name)
>> >>
>> >> end
>> >>
>> >>
>> >> The increment_number() routine checks to see if the last character
>> >> is
>> >> numeric, and if it is, increments the leftmost contiguous numeric
>> >> portion of the string.  Otherwise it appends the number zero.
>> >>
>> >> This does not allow everyone to get any name they want, but you
>> >> can't
>> >> ever satisfy that demand.  It supplies reasonable defaults very
>> >> quickly and it allows people who want really descriptive names to
>> >> try
>> >> as many as they like.
>> >>
>> >> The code's built the funny way it is so that you can corrupt the
>> >> db
>> >> that holds the last_used numbers or interrupt the process halfway
>> >> through and it still works, only slower, and it should tend to fix
>> >> its
>> >> own db on the fly when possible.
>> >>
>> >> There's no provision for simultaneous creation, but that wouldn't
>> >> be
>> >> horribly hard to add, just put a lock on the resource holding
>> >> last_used numbers.
>> >>
>> >> You'd want to reimplement in the most efficient and readable way
>> >> for
>> >> your programming language of choice.
>> >>
>> >> Did that make any sense?  I did it off the top of my head, so it
>> >> could
>> >> be terribly lame when I look at it tomorrow ;).
>> >
>> > Please don't look at it as pure programming item, nor as a single
>> > user in a small data center - in this respect you are right.
>> > Let's got to a huge organization or to the cloud.
>> >
>> > In multi tenant environment this lock means that every time a user
>> > tries to change a disk name - all the others are stack
>> > Don't forget we are discussing thousands of VMs - I'll hate to have
>> > this kind of lock just to allow for unique disk names. This is one
>> > of the reasons you use UUID to really identify the object in the
>> > DB, since it's suppose to guarantee uniqueness without the need to
>> > lock everything.
>> >
>> > And again - please look at this as an end user, why do I care that
>> > other users had decided they are going to use the same name as me?
>> > This is my human readable name and I want to choose what ever I
>> > like without considering other users. What is this self service
>> > portal worth if I can't name my VMs and Disks as I'd like to,
>> > oblivious to others?
>> >
>> > At the end of day, you want oVirt to be useful and scalable - and
>> > not just code wise correct.
>>
>>
>> how about KISS?
>> vm name is unique.
>> disk name is unique in vm.
>> treat disk name for search as vm.name + "-" + disk.name
>
> Now we are getting somewhere since this is similar to my original proposal of adding vm/domain/other to the disk search criteria
>
> But let me take your proposal a bit farther.
> I think it's safe to assume / force that tenants don't share quotas, meaning a tenant may have multiple quotas but a quota may belong to a single tenant (and I know the term tenant is not well defined, but let's assume the under any definition for this discussion it may be collapsed to a collection of users and groups)
>
> The problem is now reduced to keeping to scope boundaries.
>
> Quota name is unique in the scope of a data center
> VM name is unique in the scope of a quota (note that I intentionally don't say cluster)
> Disk name is unique in the scope of a VM or the floating scope
>
> Now to search is easy
> For VMs -> dc.quota.vm
> For disks -> dc.quota.vm.disk
> Or For floating -> dc.quota.floating.disk
> Shared disk may be accessed from any of the attached VMs
>
> when Quota is off -> you get the simple equivalent
> For VMs -> dc.vm
> For disks -> dc.vm.disk
> Or For floating -> dc.floating.disk
> Shared disk may be accessed from any of the attached VMs
>
> This is KISS, scalable, and I believe easy to understand by any user of oVirt.
>
> And in order not to bother users with providing a unique name in the scope we should always offer a name for the user to just click OK or modify, similar (may be even simpler) algorithm to what Charlie suggested.
> The above is for:
> 1. New disk
> 2. Detach disk from the last VM, meaning it becomes floating, if the name is not unique, then suggest a free name based on the current name.
>
> A nice benefit of the above is that the user may use wild cards, and get a list of matches filtered by his permissions.
> Example:
> admin searching for dc-X.quota-Y.* gets a list of all the floating disks in the quota
> user searching for the same  will get a list of all the floating disks he has permissions on.
>
> Thoughts?
>
>
>>
>> as for name uniqueness for multi tenants, yes, something we need to
>> fix.
>> would love for more inputs on how people see tenants and users
>> interact
>> in ovirt (can a user be part of more than a single tenant for
>> example,
>> but force user to choose tenant when they login if they have more
>> than one)?
>>
>> >
>> >
>> >>
>> >> --Charlie
>> >>
>> >> On Tue, Oct 23, 2012 at 1:10 PM, Simon Grinberg <simon at redhat.com>
>> >> wrote:
>> >>>
>> >>>
>> >>> ----- Original Message -----
>> >>>> From: "Charlie" <medievalist at gmail.com>
>> >>>> To: "Simon Grinberg" <simon at redhat.com>
>> >>>> Cc: "engine-devel" <engine-devel at ovirt.org>
>> >>>> Sent: Tuesday, October 23, 2012 6:51:35 PM
>> >>>> Subject: Re: [Engine-devel] alias in disk instead of name
>> >>>>
>> >>>> OK, only because you asked...
>> >>>>
>> >>>> Provide default unique names, so that users can just press enter
>> >>>> if
>> >>>> names don't matter to them.  That way you obviate the entire
>> >>>> argument;
>> >>>> people who need special naming can have it, and everybody else
>> >>>> has
>> >>>> a
>> >>>> single extra keypress or mouseclick at naming time, and
>> >>>> searching
>> >>>> works well enough.
>> >>>>
>> >>>> You can name the first one vmdrive0 and increment the numeric
>> >>>> part
>> >>>> each time a new drive is created.  Iterating until an unused
>> >>>> name
>> >>>> is
>> >>>> found isn't so computationally expensive that anyone should
>> >>>> weep,
>> >>>> especially if you store the last used number and do an
>> >>>> incrementing
>> >>>> sanity check against it at naming time.
>> >>>
>> >>> Let's say the above solved all conflicts when coming to create a
>> >>> new disk, it does seems so.
>> >>>
>> >>> Let's say that import/export if names conflict can be solved in a
>> >>> reasonable way - for example forcing (somehow and without
>> >>> bothering the user too much) a rename of the disk (How would you
>> >>> know if the conflicting name id auto-generated so can be replaced
>> >>> or user provided?, you'll have to resort to
>> >>> non-that-human-look-alike-name)
>> >>>
>> >>> How does it solve the multi-tenancy use case?
>> >>> I'm tenant A, setting up a quorum disk for my two VMs - so I call
>> >>> this disk simply quorum.
>> >>> Now comes tenant B, he is also setting up a quorum disk, so he
>> >>> tries to call his disk quorum
>> >>>
>> >>> But no,
>> >>> He'll get a popup that this name is already taken - bad luck
>> >>> buddy.
>> >>> Now he needs to guess the next available name? Would you build in
>> >>> algorithm to suggest alternatives?
>> >>> Why should tenant B care in the first place that tenant A also
>> >>> wanted to call his disk 'quorum'?
>> >>>
>> >>> Same with the VM name - but that is given for now, though I hope
>> >>> to
>> >>> convince it should change in the future.
>> >>>
>> >>> What I'm trying to say here - infrastructure is for the admin -
>> >>> so
>> >>> you can force uniqueness
>> >>> Resources like, disks and Virtual Machine belong to the end user
>> >>> thus you should let them determine their own names without being
>> >>> restricted by users of the system.
>> >>>
>> >>>
>> >>>
>> >>>>
>> >>>> People expect names to have significance, and we like it when
>> >>>> they
>> >>>> have both unique and non-unique parts.  It's part of our human
>> >>>> heritage.  Maybe whales and dolphins don't care.
>> >>>
>> >>>
>> >>>
>> >>>>
>> >>>> --Charlie
>> >>>>
>> >>>> On Tue, Oct 23, 2012 at 4:36 AM, Simon Grinberg
>> >>>> <simon at redhat.com>
>> >>>> wrote:
>> >>>>>
>> >>>>> We need more thoughts here from others, there are two different
>> >>>>> approaches on the table and more opinions are welcomed.
>> >>>>> If there are API consumers on this list then your view is more
>> >>>>> then
>> >>>>> welcomed.
>> >>>>>
>> >>>>> Thanks,
>> >>>>> Simon.
>> >>>>>
>> >>>>> ----- Original Message -----
>> >>>>>> From: "Simon Grinberg" <simon at redhat.com>
>> >>>>>> To: "Michael Pasternak" <mpastern at redhat.com>
>> >>>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
>> >>>>>> Sent: Monday, October 22, 2012 10:50:02 AM
>> >>>>>> Subject: Re: [Engine-devel] alias in disk instead of name
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> ----- Original Message -----
>> >>>>>>> From: "Michael Pasternak" <mpastern at redhat.com>
>> >>>>>>> To: "Simon Grinberg" <simon at redhat.com>
>> >>>>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
>> >>>>>>> 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" <mpastern at redhat.com>
>> >>>>>>>>> To: "Simon Grinberg" <simon at redhat.com>
>> >>>>>>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
>> >>>>>>>>> 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" <mpastern at redhat.com>
>> >>>>>>>>>>> To: "Simon Grinberg" <simon at redhat.com>
>> >>>>>>>>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
>> >>>>>>>>>>> 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" <mpastern at redhat.com>
>> >>>>>>>>>>>>>> To: "engine-devel" <engine-devel at ovirt.org>
>> >>>>>>>>>>>>>> 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 talking about /search,
>> >>>>>>> search is available only at /api/disks (i.e shared disks,
>> >>>>>>> vm/template.disks is
>> >>>>>>> irrelevant to this discussion)
>> >>>>>>
>> >>>>>> Nope I do not, but I think that our perspectives differ.
>> >>>>>> You are looking at it as strictly design issue. You have a
>> >>>>>> collection
>> >>>>>> of entities and you want a human readable search, thus you are
>> >>>>>> trying to force (rightfully) from your point of view a unique
>> >>>>>> alias/name for those.
>> >>>>>>
>> >>>>>> I taking the end user perspective, and user experience
>> >>>>>> 1. Majority of the disks have no meaning outside of a VM
>> >>>>>> scope.
>> >>>>>> 2. There are fractions of the disks that are usually shared
>> >>>>>> (this
>> >>>>>> is
>> >>>>>> the nature of shared disks)
>> >>>>>> 3. There are fractions of floating, most of the floating will
>> >>>>>> be a
>> >>>>>> transient state, while you are moving disks around.
>> >>>>>>
>> >>>>>> What I'm trying to say that forcing a user to provide a unique
>> >>>>>> name
>> >>>>>> per disk is a huge bother.
>> >>>>>> And again in the multi tenancy case, you can't enforce a
>> >>>>>> unique
>> >>>>>> alias
>> >>>>>> in the system.
>> >>>>>>
>> >>>>>> What will you say to the user in the error message?
>> >>>>>> Sorry you can't use this alias since another user that is
>> >>>>>> sharing
>> >>>>>> the
>> >>>>>> system with you already provided that name? And yes we know
>> >>>>>> you
>> >>>>>> can't see that other disk, and it you don't care about the
>> >>>>>> other
>> >>>>>> user, but still you can't use your alias since this is how our
>> >>>>>> platform designed.
>> >>>>>>
>> >>>>>> The meaning is that you must allow a for a more sophisticated
>> >>>>>> search.
>> >>>>>> Yes even in the context of the disks tab. Disks are not really
>> >>>>>> stand
>> >>>>>> alone entities, and if we keep to strict conventions like - in
>> >>>>>> any
>> >>>>>> collection an entity name must be unique, then you are making
>> >>>>>> the
>> >>>>>> system hardly usable for many users.
>> >>>>>>
>> >>>>>> So a search in disks should include other 'properties' (and
>> >>>>>> yes
>> >>>>>> I
>> >>>>>> know those are not disk properties, but this is how a user
>> >>>>>> will
>> >>>>>> look
>> >>>>>> at it) like owner,quota,vm,storage domain, etc.
>> >>>>>>
>> >>>>>> To some up - what should be unique are UUIDs of an entities,
>> >>>>>> and
>> >>>>>> infrastructure entities names (within the same scope) - all
>> >>>>>> the
>> >>>>>> rest
>> >>>>>> must not.
>> >>>>>>
>> >>>>>>
>> >>>>>>>
>> >>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>> Would you change these on import/export?
>> >>>>>>>>>>>
>> >>>>>>>>>>> would you mind elaborating on this?
>> >>>>>>>>>>
>> >>>>>>>>>> Yes,
>> >>>>>>>>>>
>> >>>>>>>>>> You are already facing a problem when importing VMs that
>> >>>>>>>>>> already
>> >>>>>>>>>> have the same name, now you increasing the problem for
>> >>>>>>>>>> disks
>> >>>>>>>>>> that
>> >>>>>>>>>> have the same alias. for same name we force clone if you
>> >>>>>>>>>> want
>> >>>>>>>>>> to
>> >>>>>>>>>> import. Why for clone just because of a disk alias (this
>> >>>>>>>>>> implies
>> >>>>>>>>>> collapse snapshots ATM) or even bother the user with
>> >>>>>>>>>> renaming
>> >>>>>>>>>> disks that he does not care about the name so he just
>> >>>>>>>>>> gave
>> >>>>>>>>>> disk
>> >>>>>>>>>> 1,
>> >>>>>>>>>> 2, 3 and so on?
>> >>>>>>>>>
>> >>>>>>>>> i see your point, but then we leave no option for the user
>> >>>>>>>>> to
>> >>>>>>>>> locate
>> >>>>>>>>> the disk,
>> >>>>>>>>> simply because he doesn't have unique identifier,
>> >>>>>>>>>
>> >>>>>>>>> just imagine user A creating disk and calling it X,
>> >>>>>>>>> then user B creating disk and calling it X, they on
>> >>>>>>>>> different
>> >>>>>>>>> domains etc., and now both want to use disk X,
>> >>>>>>>>>
>> >>>>>>>>> how they can figure out which one to pick?, by SD, by
>> >>>>>>>>> size?
>> >>>>>>>>> agree
>> >>>>>>>>> this is doesn't look well..., even more than that -
>> >>>>>>>>> someone
>> >>>>>>>>> may
>> >>>>>>>>> call
>> >>>>>>>>> this "bad design"...
>> >>>>>>>>
>> >>>>>>>> This is why the search should accept more then the name.
>> >>>>>>>> Example (vm=name, disk=name/alias)
>> >>>>>>>> Example (dc=name, disk=name/alias)
>> >>>>>>>> Example (sd=name, disk=name/alias)
>> >>>>>>>
>> >>>>>>> it's not about accepting both name/alias, it's about missing
>> >>>>>>> ability
>> >>>>>>> to identify your resource in collection.
>> >>>>>>>
>> >>>>>>>> For floating/shared on the same SD/DC/VM I would suggest a
>> >>>>>>>> warning
>> >>>>>>>> if there is a duplicate in the system - not enforcement.
>> >>>>>>>
>> >>>>>>> ok, lets assume we WARN user that his disk's name is not
>> >>>>>>> unique,
>> >>>>>>> how
>> >>>>>>> user will pick the unique name?
>> >>>>>>> implementing own code checking if new name (he wants to use)
>> >>>>>>> is
>> >>>>>>> unique or not?
>> >>>>>>>
>> >>>>>>> - this is business logic, not user's prerogative.
>> >>>>>>>
>> >>>>>>>> There is a difference between best practice and being
>> >>>>>>>> enforcing
>> >>>>>>>> up
>> >>>>>>>> to the level that it annoys some of the users.
>> >>>>>>>
>> >>>>>>> simon, when you register to email, you have to try N times
>> >>>>>>> till
>> >>>>>>> you
>> >>>>>>> find unique username,
>> >>>>>>> is it convenient? absolutely NO, is it annoying? YES, but you
>> >>>>>>> forced
>> >>>>>>> doing that so
>> >>>>>>> system will be able to identify you,
>> >>>>>>>
>> >>>>>>> it's no different in any way, good software protects
>> >>>>>>> user/itself
>> >>>>>>> even
>> >>>>>>> in cost of convenience,
>> >>>>>>>
>> >>>>>>> bottom line
>> >>>>>>> ===========
>> >>>>>>>
>> >>>>>>> - i think as long as disk not shared/floating it can have any
>> >>>>>>> name
>> >>>>>>> - in a minute disk designation changed to shared, name
>> >>>>>>> uniqueness
>> >>>>>>> should be forced (by the engine)
>> >>>>>>> - when importing vm with shared disks, name uniqueness should
>> >>>>>>> be
>> >>>>>>> forced
>> >>>>>>> - when creating vm from template with shared disk, name
>> >>>>>>> uniqueness
>> >>>>>>> should be forced
>> >>>>>>> - alias should be changed back to name (in sake of
>> >>>>>>> consistency)
>> >>>>>>> - /api/disks collection should support searching disks by
>> >>>>>>> name
>> >>>>>>> (in
>> >>>>>>> sake of consistency)
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> thoughts?
>> >>>>>>
>> >>>>>> Please look at the previous comment, that just can't work in
>> >>>>>> the
>> >>>>>> multi-tenancy case.
>> >>>>>> Name should not be unique, the warning is for the admin only,
>> >>>>>> from
>> >>>>>> the user portal a warning should be issues only if the user
>> >>>>>> provides
>> >>>>>> same name twice.
>> >>>>>>
>> >>>>>>
>> >>>>>>>
>> >>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>> --
>> >>>>>>>>>
>> >>>>>>>>> Michael Pasternak
>> >>>>>>>>> RedHat, ENG-Virtualization R&D
>> >>>>>>>>> _______________________________________________
>> >>>>>>>>> Engine-devel mailing list
>> >>>>>>>>> Engine-devel at ovirt.org
>> >>>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>> >>>>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> --
>> >>>>>>>
>> >>>>>>> Michael Pasternak
>> >>>>>>> RedHat, ENG-Virtualization R&D
>> >>>>>>> _______________________________________________
>> >>>>>>> Engine-devel mailing list
>> >>>>>>> Engine-devel at ovirt.org
>> >>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>> >>>>>>>
>> >>>>>>
>> >>>>> _______________________________________________
>> >>>>> Engine-devel mailing list
>> >>>>> Engine-devel at ovirt.org
>> >>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>> >>>>
>> >>
>> > _______________________________________________
>> > Engine-devel mailing list
>> > Engine-devel at ovirt.org
>> > http://lists.ovirt.org/mailman/listinfo/engine-devel
>> >
>>
>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel


From iheim at redhat.com  Thu Oct 25 04:01:33 2012
From: iheim at redhat.com (Itamar Heim)
Date: Thu, 25 Oct 2012 06:01:33 +0200
Subject: [Engine-devel] alias in disk instead of name
In-Reply-To: <1952920135.5438345.1351067060563.JavaMail.root@redhat.com>
References: <1952920135.5438345.1351067060563.JavaMail.root@redhat.com>
Message-ID: <5088B99D.5070000@redhat.com>

On 10/24/2012 10:24 AM, Simon Grinberg wrote:
>
>
> ----- Original Message -----
>> From: "Itamar Heim" <iheim at redhat.com>
>> To: "Simon Grinberg" <simon at redhat.com>
>> Cc: "Ewoud Kohl van Wijngaarden" <ewoud at kohlvanwijngaarden.nl>, "engine-devel" <engine-devel at ovirt.org>
>> Sent: Wednesday, October 24, 2012 6:01:53 AM
>> Subject: Re: [Engine-devel] alias in disk instead of name
>>
>> On 10/23/2012 08:07 PM, Simon Grinberg wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Charlie" <medievalist at gmail.com>
>>>> To: "Simon Grinberg" <simon at redhat.com>
>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
>>>> Sent: Tuesday, October 23, 2012 7:53:10 PM
>>>> Subject: Re: [Engine-devel] alias in disk instead of name
>>>>
>>>> Why not something like this?
>>>>
>>>> (pseudocode, using dot for string concatenation):
>>>>
>>>> $name_prefix = "vmdrive"
>>>> $name = get_last_used($name_prefix)
>>>> $already_in_use = $TRUE
>>>>
>>>> while $already_in_use {
>>>>        prompt "Name of thing? [$name] ", $name
>>>>        if name_used($name) {
>>>>            while name_used($name) {
>>>>               increment_number($name)
>>>>            }
>>>>        } else {
>>>>            $already_in_use = FALSE
>>>>        }
>>>> }
>>>>
>>>> do_whatever_you_do_with($name)
>>>>
>>>> store_last_used($name)
>>>>
>>>> end
>>>>
>>>>
>>>> The increment_number() routine checks to see if the last character
>>>> is
>>>> numeric, and if it is, increments the leftmost contiguous numeric
>>>> portion of the string.  Otherwise it appends the number zero.
>>>>
>>>> This does not allow everyone to get any name they want, but you
>>>> can't
>>>> ever satisfy that demand.  It supplies reasonable defaults very
>>>> quickly and it allows people who want really descriptive names to
>>>> try
>>>> as many as they like.
>>>>
>>>> The code's built the funny way it is so that you can corrupt the
>>>> db
>>>> that holds the last_used numbers or interrupt the process halfway
>>>> through and it still works, only slower, and it should tend to fix
>>>> its
>>>> own db on the fly when possible.
>>>>
>>>> There's no provision for simultaneous creation, but that wouldn't
>>>> be
>>>> horribly hard to add, just put a lock on the resource holding
>>>> last_used numbers.
>>>>
>>>> You'd want to reimplement in the most efficient and readable way
>>>> for
>>>> your programming language of choice.
>>>>
>>>> Did that make any sense?  I did it off the top of my head, so it
>>>> could
>>>> be terribly lame when I look at it tomorrow ;).
>>>
>>> Please don't look at it as pure programming item, nor as a single
>>> user in a small data center - in this respect you are right.
>>> Let's got to a huge organization or to the cloud.
>>>
>>> In multi tenant environment this lock means that every time a user
>>> tries to change a disk name - all the others are stack
>>> Don't forget we are discussing thousands of VMs - I'll hate to have
>>> this kind of lock just to allow for unique disk names. This is one
>>> of the reasons you use UUID to really identify the object in the
>>> DB, since it's suppose to guarantee uniqueness without the need to
>>> lock everything.
>>>
>>> And again - please look at this as an end user, why do I care that
>>> other users had decided they are going to use the same name as me?
>>> This is my human readable name and I want to choose what ever I
>>> like without considering other users. What is this self service
>>> portal worth if I can't name my VMs and Disks as I'd like to,
>>> oblivious to others?
>>>
>>> At the end of day, you want oVirt to be useful and scalable - and
>>> not just code wise correct.
>>
>>
>> how about KISS?
>> vm name is unique.
>> disk name is unique in vm.
>> treat disk name for search as vm.name + "-" + disk.name
>
> Now we are getting somewhere since this is similar to my original proposal of adding vm/domain/other to the disk search criteria
>
> But let me take your proposal a bit farther.
> I think it's safe to assume / force that tenants don't share quotas, meaning a tenant may have multiple quotas but a quota may belong to a single tenant (and I know the term tenant is not well defined, but let's assume the under any definition for this discussion it may be collapsed to a collection of users and groups)
>
> The problem is now reduced to keeping to scope boundaries.
>
> Quota name is unique in the scope of a data center
> VM name is unique in the scope of a quota (note that I intentionally don't say cluster)
> Disk name is unique in the scope of a VM or the floating scope
>
> Now to search is easy
> For VMs -> dc.quota.vm
> For disks -> dc.quota.vm.disk
> Or For floating -> dc.quota.floating.disk
> Shared disk may be accessed from any of the attached VMs
>
> when Quota is off -> you get the simple equivalent
> For VMs -> dc.vm
> For disks -> dc.vm.disk
> Or For floating -> dc.floating.disk
> Shared disk may be accessed from any of the attached VMs

most users will probably be part of a single tenant.
I suggest a simpler solution:
for now:
for VMs -> vm
for disks -> vm.disk

with tenatns
for vMs -> [tenant] vm
for disks -> [tenant] vm.disk

why?
i think a user with multiple tenants is a unique case, so while i don't 
want to prevent it in the system, i don't think we should make the 
system more complex for it.

so i think entities should be unique at tenant level[see template 
below], not dc level (a tenant may not know tomorrow what a DC is if we 
abstract it for them under quota via some magic).
and i think to make it simple, a user with a single tenant will just not 
need to specify it, and a user with multiple tenants may have to specify 
it at login time (well, its a post login prompt for UI, and a 
header/field in REST API).

if we see users with multiple tenants are very common, we can remove 
this requirement, and even then i would claim the tenant is required 
only if the query returns more than a single entry, so you would fail it 
on "ambiguous result", please provide 'fqdn' (tenant.vm).

[template] there is one entity that defies this rule which is the 
template. since you want to be able to make your template public, or 
give permissions on your templates to some other tenants.
so i think 'public' is a predefined tenant.

thinking about this some more, i don't have an issue with tenants (like 
users), sharing resources via the permissions model.

and for uniqueness, same rules apply - if user gets more than a single 
entity, its ambiguous, and they need to prefix it with the tenant (they 
can choose to always do so).

another approach:
- we could say only users with more than a single tenant must always
   specify the tenant
- to use an entity from another tenant (public, or other), they must 
specify the entity prefix as well.

thinking about it some more, maybe i like this even better.

>
> This is KISS, scalable, and I believe easy to understand by any user of oVirt.
>
> And in order not to bother users with providing a unique name in the scope we should always offer a name for the user to just click OK or modify, similar (may be even simpler) algorithm to what Charlie suggested.
> The above is for:
> 1. New disk
> 2. Detach disk from the last VM, meaning it becomes floating, if the name is not unique, then suggest a free name based on the current name.

isn't this why we called the field 'alias'? since the 'name' of the VM 
is always unique in the system (a uuid)?

>
> A nice benefit of the above is that the user may use wild cards, and get a list of matches filtered by his permissions.
> Example:
> admin searching for dc-X.quota-Y.* gets a list of all the floating disks in the quota
> user searching for the same  will get a list of all the floating disks he has permissions on.
>
> Thoughts?
>
>
>>
>> as for name uniqueness for multi tenants, yes, something we need to
>> fix.
>> would love for more inputs on how people see tenants and users
>> interact
>> in ovirt (can a user be part of more than a single tenant for
>> example,
>> but force user to choose tenant when they login if they have more
>> than one)?
>>
>>>
>>>
>>>>
>>>> --Charlie
>>>>
>>>> On Tue, Oct 23, 2012 at 1:10 PM, Simon Grinberg <simon at redhat.com>
>>>> wrote:
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Charlie" <medievalist at gmail.com>
>>>>>> To: "Simon Grinberg" <simon at redhat.com>
>>>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
>>>>>> Sent: Tuesday, October 23, 2012 6:51:35 PM
>>>>>> Subject: Re: [Engine-devel] alias in disk instead of name
>>>>>>
>>>>>> OK, only because you asked...
>>>>>>
>>>>>> Provide default unique names, so that users can just press enter
>>>>>> if
>>>>>> names don't matter to them.  That way you obviate the entire
>>>>>> argument;
>>>>>> people who need special naming can have it, and everybody else
>>>>>> has
>>>>>> a
>>>>>> single extra keypress or mouseclick at naming time, and
>>>>>> searching
>>>>>> works well enough.
>>>>>>
>>>>>> You can name the first one vmdrive0 and increment the numeric
>>>>>> part
>>>>>> each time a new drive is created.  Iterating until an unused
>>>>>> name
>>>>>> is
>>>>>> found isn't so computationally expensive that anyone should
>>>>>> weep,
>>>>>> especially if you store the last used number and do an
>>>>>> incrementing
>>>>>> sanity check against it at naming time.
>>>>>
>>>>> Let's say the above solved all conflicts when coming to create a
>>>>> new disk, it does seems so.
>>>>>
>>>>> Let's say that import/export if names conflict can be solved in a
>>>>> reasonable way - for example forcing (somehow and without
>>>>> bothering the user too much) a rename of the disk (How would you
>>>>> know if the conflicting name id auto-generated so can be replaced
>>>>> or user provided?, you'll have to resort to
>>>>> non-that-human-look-alike-name)
>>>>>
>>>>> How does it solve the multi-tenancy use case?
>>>>> I'm tenant A, setting up a quorum disk for my two VMs - so I call
>>>>> this disk simply quorum.
>>>>> Now comes tenant B, he is also setting up a quorum disk, so he
>>>>> tries to call his disk quorum
>>>>>
>>>>> But no,
>>>>> He'll get a popup that this name is already taken - bad luck
>>>>> buddy.
>>>>> Now he needs to guess the next available name? Would you build in
>>>>> algorithm to suggest alternatives?
>>>>> Why should tenant B care in the first place that tenant A also
>>>>> wanted to call his disk 'quorum'?
>>>>>
>>>>> Same with the VM name - but that is given for now, though I hope
>>>>> to
>>>>> convince it should change in the future.
>>>>>
>>>>> What I'm trying to say here - infrastructure is for the admin -
>>>>> so
>>>>> you can force uniqueness
>>>>> Resources like, disks and Virtual Machine belong to the end user
>>>>> thus you should let them determine their own names without being
>>>>> restricted by users of the system.
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> People expect names to have significance, and we like it when
>>>>>> they
>>>>>> have both unique and non-unique parts.  It's part of our human
>>>>>> heritage.  Maybe whales and dolphins don't care.
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> --Charlie
>>>>>>
>>>>>> On Tue, Oct 23, 2012 at 4:36 AM, Simon Grinberg
>>>>>> <simon at redhat.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> We need more thoughts here from others, there are two different
>>>>>>> approaches on the table and more opinions are welcomed.
>>>>>>> If there are API consumers on this list then your view is more
>>>>>>> then
>>>>>>> welcomed.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Simon.
>>>>>>>
>>>>>>> ----- Original Message -----
>>>>>>>> From: "Simon Grinberg" <simon at redhat.com>
>>>>>>>> To: "Michael Pasternak" <mpastern at redhat.com>
>>>>>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
>>>>>>>> Sent: Monday, October 22, 2012 10:50:02 AM
>>>>>>>> Subject: Re: [Engine-devel] alias in disk instead of name
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ----- Original Message -----
>>>>>>>>> From: "Michael Pasternak" <mpastern at redhat.com>
>>>>>>>>> To: "Simon Grinberg" <simon at redhat.com>
>>>>>>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
>>>>>>>>> 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" <mpastern at redhat.com>
>>>>>>>>>>> To: "Simon Grinberg" <simon at redhat.com>
>>>>>>>>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
>>>>>>>>>>> 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" <mpastern at redhat.com>
>>>>>>>>>>>>> To: "Simon Grinberg" <simon at redhat.com>
>>>>>>>>>>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
>>>>>>>>>>>>> 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" <mpastern at redhat.com>
>>>>>>>>>>>>>>>> To: "engine-devel" <engine-devel at ovirt.org>
>>>>>>>>>>>>>>>> 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 talking about /search,
>>>>>>>>> search is available only at /api/disks (i.e shared disks,
>>>>>>>>> vm/template.disks is
>>>>>>>>> irrelevant to this discussion)
>>>>>>>>
>>>>>>>> Nope I do not, but I think that our perspectives differ.
>>>>>>>> You are looking at it as strictly design issue. You have a
>>>>>>>> collection
>>>>>>>> of entities and you want a human readable search, thus you are
>>>>>>>> trying to force (rightfully) from your point of view a unique
>>>>>>>> alias/name for those.
>>>>>>>>
>>>>>>>> I taking the end user perspective, and user experience
>>>>>>>> 1. Majority of the disks have no meaning outside of a VM
>>>>>>>> scope.
>>>>>>>> 2. There are fractions of the disks that are usually shared
>>>>>>>> (this
>>>>>>>> is
>>>>>>>> the nature of shared disks)
>>>>>>>> 3. There are fractions of floating, most of the floating will
>>>>>>>> be a
>>>>>>>> transient state, while you are moving disks around.
>>>>>>>>
>>>>>>>> What I'm trying to say that forcing a user to provide a unique
>>>>>>>> name
>>>>>>>> per disk is a huge bother.
>>>>>>>> And again in the multi tenancy case, you can't enforce a
>>>>>>>> unique
>>>>>>>> alias
>>>>>>>> in the system.
>>>>>>>>
>>>>>>>> What will you say to the user in the error message?
>>>>>>>> Sorry you can't use this alias since another user that is
>>>>>>>> sharing
>>>>>>>> the
>>>>>>>> system with you already provided that name? And yes we know
>>>>>>>> you
>>>>>>>> can't see that other disk, and it you don't care about the
>>>>>>>> other
>>>>>>>> user, but still you can't use your alias since this is how our
>>>>>>>> platform designed.
>>>>>>>>
>>>>>>>> The meaning is that you must allow a for a more sophisticated
>>>>>>>> search.
>>>>>>>> Yes even in the context of the disks tab. Disks are not really
>>>>>>>> stand
>>>>>>>> alone entities, and if we keep to strict conventions like - in
>>>>>>>> any
>>>>>>>> collection an entity name must be unique, then you are making
>>>>>>>> the
>>>>>>>> system hardly usable for many users.
>>>>>>>>
>>>>>>>> So a search in disks should include other 'properties' (and
>>>>>>>> yes
>>>>>>>> I
>>>>>>>> know those are not disk properties, but this is how a user
>>>>>>>> will
>>>>>>>> look
>>>>>>>> at it) like owner,quota,vm,storage domain, etc.
>>>>>>>>
>>>>>>>> To some up - what should be unique are UUIDs of an entities,
>>>>>>>> and
>>>>>>>> infrastructure entities names (within the same scope) - all
>>>>>>>> the
>>>>>>>> rest
>>>>>>>> must not.
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Would you change these on import/export?
>>>>>>>>>>>>>
>>>>>>>>>>>>> would you mind elaborating on this?
>>>>>>>>>>>>
>>>>>>>>>>>> Yes,
>>>>>>>>>>>>
>>>>>>>>>>>> You are already facing a problem when importing VMs that
>>>>>>>>>>>> already
>>>>>>>>>>>> have the same name, now you increasing the problem for
>>>>>>>>>>>> disks
>>>>>>>>>>>> that
>>>>>>>>>>>> have the same alias. for same name we force clone if you
>>>>>>>>>>>> want
>>>>>>>>>>>> to
>>>>>>>>>>>> import. Why for clone just because of a disk alias (this
>>>>>>>>>>>> implies
>>>>>>>>>>>> collapse snapshots ATM) or even bother the user with
>>>>>>>>>>>> renaming
>>>>>>>>>>>> disks that he does not care about the name so he just
>>>>>>>>>>>> gave
>>>>>>>>>>>> disk
>>>>>>>>>>>> 1,
>>>>>>>>>>>> 2, 3 and so on?
>>>>>>>>>>>
>>>>>>>>>>> i see your point, but then we leave no option for the user
>>>>>>>>>>> to
>>>>>>>>>>> locate
>>>>>>>>>>> the disk,
>>>>>>>>>>> simply because he doesn't have unique identifier,
>>>>>>>>>>>
>>>>>>>>>>> just imagine user A creating disk and calling it X,
>>>>>>>>>>> then user B creating disk and calling it X, they on
>>>>>>>>>>> different
>>>>>>>>>>> domains etc., and now both want to use disk X,
>>>>>>>>>>>
>>>>>>>>>>> how they can figure out which one to pick?, by SD, by
>>>>>>>>>>> size?
>>>>>>>>>>> agree
>>>>>>>>>>> this is doesn't look well..., even more than that -
>>>>>>>>>>> someone
>>>>>>>>>>> may
>>>>>>>>>>> call
>>>>>>>>>>> this "bad design"...
>>>>>>>>>>
>>>>>>>>>> This is why the search should accept more then the name.
>>>>>>>>>> Example (vm=name, disk=name/alias)
>>>>>>>>>> Example (dc=name, disk=name/alias)
>>>>>>>>>> Example (sd=name, disk=name/alias)
>>>>>>>>>
>>>>>>>>> it's not about accepting both name/alias, it's about missing
>>>>>>>>> ability
>>>>>>>>> to identify your resource in collection.
>>>>>>>>>
>>>>>>>>>> For floating/shared on the same SD/DC/VM I would suggest a
>>>>>>>>>> warning
>>>>>>>>>> if there is a duplicate in the system - not enforcement.
>>>>>>>>>
>>>>>>>>> ok, lets assume we WARN user that his disk's name is not
>>>>>>>>> unique,
>>>>>>>>> how
>>>>>>>>> user will pick the unique name?
>>>>>>>>> implementing own code checking if new name (he wants to use)
>>>>>>>>> is
>>>>>>>>> unique or not?
>>>>>>>>>
>>>>>>>>> - this is business logic, not user's prerogative.
>>>>>>>>>
>>>>>>>>>> There is a difference between best practice and being
>>>>>>>>>> enforcing
>>>>>>>>>> up
>>>>>>>>>> to the level that it annoys some of the users.
>>>>>>>>>
>>>>>>>>> simon, when you register to email, you have to try N times
>>>>>>>>> till
>>>>>>>>> you
>>>>>>>>> find unique username,
>>>>>>>>> is it convenient? absolutely NO, is it annoying? YES, but you
>>>>>>>>> forced
>>>>>>>>> doing that so
>>>>>>>>> system will be able to identify you,
>>>>>>>>>
>>>>>>>>> it's no different in any way, good software protects
>>>>>>>>> user/itself
>>>>>>>>> even
>>>>>>>>> in cost of convenience,
>>>>>>>>>
>>>>>>>>> bottom line
>>>>>>>>> ===========
>>>>>>>>>
>>>>>>>>> - i think as long as disk not shared/floating it can have any
>>>>>>>>> name
>>>>>>>>> - in a minute disk designation changed to shared, name
>>>>>>>>> uniqueness
>>>>>>>>> should be forced (by the engine)
>>>>>>>>> - when importing vm with shared disks, name uniqueness should
>>>>>>>>> be
>>>>>>>>> forced
>>>>>>>>> - when creating vm from template with shared disk, name
>>>>>>>>> uniqueness
>>>>>>>>> should be forced
>>>>>>>>> - alias should be changed back to name (in sake of
>>>>>>>>> consistency)
>>>>>>>>> - /api/disks collection should support searching disks by
>>>>>>>>> name
>>>>>>>>> (in
>>>>>>>>> sake of consistency)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> thoughts?
>>>>>>>>
>>>>>>>> Please look at the previous comment, that just can't work in
>>>>>>>> the
>>>>>>>> multi-tenancy case.
>>>>>>>> Name should not be unique, the warning is for the admin only,
>>>>>>>> from
>>>>>>>> the user portal a warning should be issues only if the user
>>>>>>>> provides
>>>>>>>> same name twice.
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>>
>>>>>>>>>>> Michael Pasternak
>>>>>>>>>>> RedHat, ENG-Virtualization R&D
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Engine-devel mailing list
>>>>>>>>>>> Engine-devel at ovirt.org
>>>>>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>>
>>>>>>>>> Michael Pasternak
>>>>>>>>> RedHat, ENG-Virtualization R&D
>>>>>>>>> _______________________________________________
>>>>>>>>> Engine-devel mailing list
>>>>>>>>> Engine-devel at ovirt.org
>>>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>>>>>
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Engine-devel mailing list
>>>>>>> Engine-devel at ovirt.org
>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>>
>>>>
>>> _______________________________________________
>>> Engine-devel mailing list
>>> Engine-devel at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>
>>
>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>




From simon at redhat.com  Thu Oct 25 10:34:30 2012
From: simon at redhat.com (Simon Grinberg)
Date: Thu, 25 Oct 2012 06:34:30 -0400 (EDT)
Subject: [Engine-devel] alias in disk instead of name
In-Reply-To: <5088B99D.5070000@redhat.com>
Message-ID: <49630694.6147929.1351161270409.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Simon Grinberg" <simon at redhat.com>
> Cc: "Ewoud Kohl van Wijngaarden" <ewoud at kohlvanwijngaarden.nl>, "engine-devel" <engine-devel at ovirt.org>
> Sent: Thursday, October 25, 2012 6:01:33 AM
> Subject: Re: [Engine-devel] alias in disk instead of name
> 
> On 10/24/2012 10:24 AM, Simon Grinberg wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Itamar Heim" <iheim at redhat.com>
> >> To: "Simon Grinberg" <simon at redhat.com>
> >> Cc: "Ewoud Kohl van Wijngaarden" <ewoud at kohlvanwijngaarden.nl>,
> >> "engine-devel" <engine-devel at ovirt.org>
> >> Sent: Wednesday, October 24, 2012 6:01:53 AM
> >> Subject: Re: [Engine-devel] alias in disk instead of name
> >>
> >> On 10/23/2012 08:07 PM, Simon Grinberg wrote:
> >>>
> >>>
> >>> ----- Original Message -----
> >>>> From: "Charlie" <medievalist at gmail.com>
> >>>> To: "Simon Grinberg" <simon at redhat.com>
> >>>> Cc: "engine-devel" <engine-devel at ovirt.org>
> >>>> Sent: Tuesday, October 23, 2012 7:53:10 PM
> >>>> Subject: Re: [Engine-devel] alias in disk instead of name
> >>>>
> >>>> Why not something like this?
> >>>>
> >>>> (pseudocode, using dot for string concatenation):
> >>>>
> >>>> $name_prefix = "vmdrive"
> >>>> $name = get_last_used($name_prefix)
> >>>> $already_in_use = $TRUE
> >>>>
> >>>> while $already_in_use {
> >>>>        prompt "Name of thing? [$name] ", $name
> >>>>        if name_used($name) {
> >>>>            while name_used($name) {
> >>>>               increment_number($name)
> >>>>            }
> >>>>        } else {
> >>>>            $already_in_use = FALSE
> >>>>        }
> >>>> }
> >>>>
> >>>> do_whatever_you_do_with($name)
> >>>>
> >>>> store_last_used($name)
> >>>>
> >>>> end
> >>>>
> >>>>
> >>>> The increment_number() routine checks to see if the last
> >>>> character
> >>>> is
> >>>> numeric, and if it is, increments the leftmost contiguous
> >>>> numeric
> >>>> portion of the string.  Otherwise it appends the number zero.
> >>>>
> >>>> This does not allow everyone to get any name they want, but you
> >>>> can't
> >>>> ever satisfy that demand.  It supplies reasonable defaults very
> >>>> quickly and it allows people who want really descriptive names
> >>>> to
> >>>> try
> >>>> as many as they like.
> >>>>
> >>>> The code's built the funny way it is so that you can corrupt the
> >>>> db
> >>>> that holds the last_used numbers or interrupt the process
> >>>> halfway
> >>>> through and it still works, only slower, and it should tend to
> >>>> fix
> >>>> its
> >>>> own db on the fly when possible.
> >>>>
> >>>> There's no provision for simultaneous creation, but that
> >>>> wouldn't
> >>>> be
> >>>> horribly hard to add, just put a lock on the resource holding
> >>>> last_used numbers.
> >>>>
> >>>> You'd want to reimplement in the most efficient and readable way
> >>>> for
> >>>> your programming language of choice.
> >>>>
> >>>> Did that make any sense?  I did it off the top of my head, so it
> >>>> could
> >>>> be terribly lame when I look at it tomorrow ;).
> >>>
> >>> Please don't look at it as pure programming item, nor as a single
> >>> user in a small data center - in this respect you are right.
> >>> Let's got to a huge organization or to the cloud.
> >>>
> >>> In multi tenant environment this lock means that every time a
> >>> user
> >>> tries to change a disk name - all the others are stack
> >>> Don't forget we are discussing thousands of VMs - I'll hate to
> >>> have
> >>> this kind of lock just to allow for unique disk names. This is
> >>> one
> >>> of the reasons you use UUID to really identify the object in the
> >>> DB, since it's suppose to guarantee uniqueness without the need
> >>> to
> >>> lock everything.
> >>>
> >>> And again - please look at this as an end user, why do I care
> >>> that
> >>> other users had decided they are going to use the same name as
> >>> me?
> >>> This is my human readable name and I want to choose what ever I
> >>> like without considering other users. What is this self service
> >>> portal worth if I can't name my VMs and Disks as I'd like to,
> >>> oblivious to others?
> >>>
> >>> At the end of day, you want oVirt to be useful and scalable - and
> >>> not just code wise correct.
> >>
> >>
> >> how about KISS?
> >> vm name is unique.
> >> disk name is unique in vm.
> >> treat disk name for search as vm.name + "-" + disk.name
> >
> > Now we are getting somewhere since this is similar to my original
> > proposal of adding vm/domain/other to the disk search criteria
> >
> > But let me take your proposal a bit farther.
> > I think it's safe to assume / force that tenants don't share
> > quotas, meaning a tenant may have multiple quotas but a quota may
> > belong to a single tenant (and I know the term tenant is not well
> > defined, but let's assume the under any definition for this
> > discussion it may be collapsed to a collection of users and
> > groups)
> >
> > The problem is now reduced to keeping to scope boundaries.
> >
> > Quota name is unique in the scope of a data center
> > VM name is unique in the scope of a quota (note that I
> > intentionally don't say cluster)
> > Disk name is unique in the scope of a VM or the floating scope
> >
> > Now to search is easy
> > For VMs -> dc.quota.vm
> > For disks -> dc.quota.vm.disk
> > Or For floating -> dc.quota.floating.disk
> > Shared disk may be accessed from any of the attached VMs
> >
> > when Quota is off -> you get the simple equivalent
> > For VMs -> dc.vm
> > For disks -> dc.vm.disk
> > Or For floating -> dc.floating.disk
> > Shared disk may be accessed from any of the attached VMs
> 
> most users will probably be part of a single tenant.
> I suggest a simpler solution:
> for now:
> for VMs -> vm
> for disks -> vm.disk
> 
> with tenatns
> for vMs -> [tenant] vm
> for disks -> [tenant] vm.disk
> 
> why?
> i think a user with multiple tenants is a unique case, so while i
> don't
> want to prevent it in the system, i don't think we should make the
> system more complex for it.
> 
> so i think entities should be unique at tenant level[see template
> below], not dc level (a tenant may not know tomorrow what a DC is if
> we
> abstract it for them under quota via some magic).
> and i think to make it simple, a user with a single tenant will just
> not
> need to specify it, and a user with multiple tenants may have to
> specify
> it at login time (well, its a post login prompt for UI, and a
> header/field in REST API).
> 
> if we see users with multiple tenants are very common, we can remove
> this requirement, and even then i would claim the tenant is required
> only if the query returns more than a single entry, so you would fail
> it
> on "ambiguous result", please provide 'fqdn' (tenant.vm).
> 
> [template] there is one entity that defies this rule which is the
> template. since you want to be able to make your template public, or
> give permissions on your templates to some other tenants.
> so i think 'public' is a predefined tenant.
> 
> thinking about this some more, i don't have an issue with tenants
> (like
> users), sharing resources via the permissions model.
> 
> and for uniqueness, same rules apply - if user gets more than a
> single
> entity, its ambiguous, and they need to prefix it with the tenant
> (they
> can choose to always do so).
> 
> another approach:
> - we could say only users with more than a single tenant must always
>    specify the tenant
> - to use an entity from another tenant (public, or other), they must
> specify the entity prefix as well.
> 
> thinking about it some more, maybe i like this even better.

As long as it's clear that VMs names unique in tenant scope and Disks names are unique in the VM scope then I see nothing wrong with using tenants, I just tried to stick to entities that are currently available like DC and Quotas, and since Quota is a DC scope entity I've suggest those. I'm perfectly fine with tenant. Your proposal is exactly what I've meant id you s/dc.quota/tenant 

The last approach that you like so much is a must for admin roles queries, and yes covers users that belong to multiple tenants (in private clouds, there is a good probability this will happen) 

Just a minor addition - for floating disk you still need the floating scope (notice I don't say floating VM, I would prefer to avoid another 'blank template' case)

So +1

> 
> >
> > This is KISS, scalable, and I believe easy to understand by any
> > user of oVirt.
> >
> > And in order not to bother users with providing a unique name in
> > the scope we should always offer a name for the user to just click
> > OK or modify, similar (may be even simpler) algorithm to what
> > Charlie suggested.
> > The above is for:
> > 1. New disk
> > 2. Detach disk from the last VM, meaning it becomes floating, if
> > the name is not unique, then suggest a free name based on the
> > current name.
> 
> isn't this why we called the field 'alias'? since the 'name' of the
> VM
> is always unique in the system (a uuid)?
> 
> >
> > A nice benefit of the above is that the user may use wild cards,
> > and get a list of matches filtered by his permissions.
> > Example:
> > admin searching for dc-X.quota-Y.* gets a list of all the floating
> > disks in the quota
> > user searching for the same  will get a list of all the floating
> > disks he has permissions on.
> >
> > Thoughts?
> >
> >
> >>
> >> as for name uniqueness for multi tenants, yes, something we need
> >> to
> >> fix.
> >> would love for more inputs on how people see tenants and users
> >> interact
> >> in ovirt (can a user be part of more than a single tenant for
> >> example,
> >> but force user to choose tenant when they login if they have more
> >> than one)?
> >>
> >>>
> >>>
> >>>>
> >>>> --Charlie
> >>>>
> >>>> On Tue, Oct 23, 2012 at 1:10 PM, Simon Grinberg
> >>>> <simon at redhat.com>
> >>>> wrote:
> >>>>>
> >>>>>
> >>>>> ----- Original Message -----
> >>>>>> From: "Charlie" <medievalist at gmail.com>
> >>>>>> To: "Simon Grinberg" <simon at redhat.com>
> >>>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
> >>>>>> Sent: Tuesday, October 23, 2012 6:51:35 PM
> >>>>>> Subject: Re: [Engine-devel] alias in disk instead of name
> >>>>>>
> >>>>>> OK, only because you asked...
> >>>>>>
> >>>>>> Provide default unique names, so that users can just press
> >>>>>> enter
> >>>>>> if
> >>>>>> names don't matter to them.  That way you obviate the entire
> >>>>>> argument;
> >>>>>> people who need special naming can have it, and everybody else
> >>>>>> has
> >>>>>> a
> >>>>>> single extra keypress or mouseclick at naming time, and
> >>>>>> searching
> >>>>>> works well enough.
> >>>>>>
> >>>>>> You can name the first one vmdrive0 and increment the numeric
> >>>>>> part
> >>>>>> each time a new drive is created.  Iterating until an unused
> >>>>>> name
> >>>>>> is
> >>>>>> found isn't so computationally expensive that anyone should
> >>>>>> weep,
> >>>>>> especially if you store the last used number and do an
> >>>>>> incrementing
> >>>>>> sanity check against it at naming time.
> >>>>>
> >>>>> Let's say the above solved all conflicts when coming to create
> >>>>> a
> >>>>> new disk, it does seems so.
> >>>>>
> >>>>> Let's say that import/export if names conflict can be solved in
> >>>>> a
> >>>>> reasonable way - for example forcing (somehow and without
> >>>>> bothering the user too much) a rename of the disk (How would
> >>>>> you
> >>>>> know if the conflicting name id auto-generated so can be
> >>>>> replaced
> >>>>> or user provided?, you'll have to resort to
> >>>>> non-that-human-look-alike-name)
> >>>>>
> >>>>> How does it solve the multi-tenancy use case?
> >>>>> I'm tenant A, setting up a quorum disk for my two VMs - so I
> >>>>> call
> >>>>> this disk simply quorum.
> >>>>> Now comes tenant B, he is also setting up a quorum disk, so he
> >>>>> tries to call his disk quorum
> >>>>>
> >>>>> But no,
> >>>>> He'll get a popup that this name is already taken - bad luck
> >>>>> buddy.
> >>>>> Now he needs to guess the next available name? Would you build
> >>>>> in
> >>>>> algorithm to suggest alternatives?
> >>>>> Why should tenant B care in the first place that tenant A also
> >>>>> wanted to call his disk 'quorum'?
> >>>>>
> >>>>> Same with the VM name - but that is given for now, though I
> >>>>> hope
> >>>>> to
> >>>>> convince it should change in the future.
> >>>>>
> >>>>> What I'm trying to say here - infrastructure is for the admin -
> >>>>> so
> >>>>> you can force uniqueness
> >>>>> Resources like, disks and Virtual Machine belong to the end
> >>>>> user
> >>>>> thus you should let them determine their own names without
> >>>>> being
> >>>>> restricted by users of the system.
> >>>>>
> >>>>>
> >>>>>
> >>>>>>
> >>>>>> People expect names to have significance, and we like it when
> >>>>>> they
> >>>>>> have both unique and non-unique parts.  It's part of our human
> >>>>>> heritage.  Maybe whales and dolphins don't care.
> >>>>>
> >>>>>
> >>>>>
> >>>>>>
> >>>>>> --Charlie
> >>>>>>
> >>>>>> On Tue, Oct 23, 2012 at 4:36 AM, Simon Grinberg
> >>>>>> <simon at redhat.com>
> >>>>>> wrote:
> >>>>>>>
> >>>>>>> We need more thoughts here from others, there are two
> >>>>>>> different
> >>>>>>> approaches on the table and more opinions are welcomed.
> >>>>>>> If there are API consumers on this list then your view is
> >>>>>>> more
> >>>>>>> then
> >>>>>>> welcomed.
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>> Simon.
> >>>>>>>
> >>>>>>> ----- Original Message -----
> >>>>>>>> From: "Simon Grinberg" <simon at redhat.com>
> >>>>>>>> To: "Michael Pasternak" <mpastern at redhat.com>
> >>>>>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
> >>>>>>>> Sent: Monday, October 22, 2012 10:50:02 AM
> >>>>>>>> Subject: Re: [Engine-devel] alias in disk instead of name
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> ----- Original Message -----
> >>>>>>>>> From: "Michael Pasternak" <mpastern at redhat.com>
> >>>>>>>>> To: "Simon Grinberg" <simon at redhat.com>
> >>>>>>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
> >>>>>>>>> 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" <mpastern at redhat.com>
> >>>>>>>>>>> To: "Simon Grinberg" <simon at redhat.com>
> >>>>>>>>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
> >>>>>>>>>>> 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" <mpastern at redhat.com>
> >>>>>>>>>>>>> To: "Simon Grinberg" <simon at redhat.com>
> >>>>>>>>>>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
> >>>>>>>>>>>>> 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" <mpastern at redhat.com>
> >>>>>>>>>>>>>>>> To: "engine-devel" <engine-devel at ovirt.org>
> >>>>>>>>>>>>>>>> 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 talking about /search,
> >>>>>>>>> search is available only at /api/disks (i.e shared disks,
> >>>>>>>>> vm/template.disks is
> >>>>>>>>> irrelevant to this discussion)
> >>>>>>>>
> >>>>>>>> Nope I do not, but I think that our perspectives differ.
> >>>>>>>> You are looking at it as strictly design issue. You have a
> >>>>>>>> collection
> >>>>>>>> of entities and you want a human readable search, thus you
> >>>>>>>> are
> >>>>>>>> trying to force (rightfully) from your point of view a
> >>>>>>>> unique
> >>>>>>>> alias/name for those.
> >>>>>>>>
> >>>>>>>> I taking the end user perspective, and user experience
> >>>>>>>> 1. Majority of the disks have no meaning outside of a VM
> >>>>>>>> scope.
> >>>>>>>> 2. There are fractions of the disks that are usually shared
> >>>>>>>> (this
> >>>>>>>> is
> >>>>>>>> the nature of shared disks)
> >>>>>>>> 3. There are fractions of floating, most of the floating
> >>>>>>>> will
> >>>>>>>> be a
> >>>>>>>> transient state, while you are moving disks around.
> >>>>>>>>
> >>>>>>>> What I'm trying to say that forcing a user to provide a
> >>>>>>>> unique
> >>>>>>>> name
> >>>>>>>> per disk is a huge bother.
> >>>>>>>> And again in the multi tenancy case, you can't enforce a
> >>>>>>>> unique
> >>>>>>>> alias
> >>>>>>>> in the system.
> >>>>>>>>
> >>>>>>>> What will you say to the user in the error message?
> >>>>>>>> Sorry you can't use this alias since another user that is
> >>>>>>>> sharing
> >>>>>>>> the
> >>>>>>>> system with you already provided that name? And yes we know
> >>>>>>>> you
> >>>>>>>> can't see that other disk, and it you don't care about the
> >>>>>>>> other
> >>>>>>>> user, but still you can't use your alias since this is how
> >>>>>>>> our
> >>>>>>>> platform designed.
> >>>>>>>>
> >>>>>>>> The meaning is that you must allow a for a more
> >>>>>>>> sophisticated
> >>>>>>>> search.
> >>>>>>>> Yes even in the context of the disks tab. Disks are not
> >>>>>>>> really
> >>>>>>>> stand
> >>>>>>>> alone entities, and if we keep to strict conventions like -
> >>>>>>>> in
> >>>>>>>> any
> >>>>>>>> collection an entity name must be unique, then you are
> >>>>>>>> making
> >>>>>>>> the
> >>>>>>>> system hardly usable for many users.
> >>>>>>>>
> >>>>>>>> So a search in disks should include other 'properties' (and
> >>>>>>>> yes
> >>>>>>>> I
> >>>>>>>> know those are not disk properties, but this is how a user
> >>>>>>>> will
> >>>>>>>> look
> >>>>>>>> at it) like owner,quota,vm,storage domain, etc.
> >>>>>>>>
> >>>>>>>> To some up - what should be unique are UUIDs of an entities,
> >>>>>>>> and
> >>>>>>>> infrastructure entities names (within the same scope) - all
> >>>>>>>> the
> >>>>>>>> rest
> >>>>>>>> must not.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> Would you change these on import/export?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> would you mind elaborating on this?
> >>>>>>>>>>>>
> >>>>>>>>>>>> Yes,
> >>>>>>>>>>>>
> >>>>>>>>>>>> You are already facing a problem when importing VMs that
> >>>>>>>>>>>> already
> >>>>>>>>>>>> have the same name, now you increasing the problem for
> >>>>>>>>>>>> disks
> >>>>>>>>>>>> that
> >>>>>>>>>>>> have the same alias. for same name we force clone if you
> >>>>>>>>>>>> want
> >>>>>>>>>>>> to
> >>>>>>>>>>>> import. Why for clone just because of a disk alias (this
> >>>>>>>>>>>> implies
> >>>>>>>>>>>> collapse snapshots ATM) or even bother the user with
> >>>>>>>>>>>> renaming
> >>>>>>>>>>>> disks that he does not care about the name so he just
> >>>>>>>>>>>> gave
> >>>>>>>>>>>> disk
> >>>>>>>>>>>> 1,
> >>>>>>>>>>>> 2, 3 and so on?
> >>>>>>>>>>>
> >>>>>>>>>>> i see your point, but then we leave no option for the
> >>>>>>>>>>> user
> >>>>>>>>>>> to
> >>>>>>>>>>> locate
> >>>>>>>>>>> the disk,
> >>>>>>>>>>> simply because he doesn't have unique identifier,
> >>>>>>>>>>>
> >>>>>>>>>>> just imagine user A creating disk and calling it X,
> >>>>>>>>>>> then user B creating disk and calling it X, they on
> >>>>>>>>>>> different
> >>>>>>>>>>> domains etc., and now both want to use disk X,
> >>>>>>>>>>>
> >>>>>>>>>>> how they can figure out which one to pick?, by SD, by
> >>>>>>>>>>> size?
> >>>>>>>>>>> agree
> >>>>>>>>>>> this is doesn't look well..., even more than that -
> >>>>>>>>>>> someone
> >>>>>>>>>>> may
> >>>>>>>>>>> call
> >>>>>>>>>>> this "bad design"...
> >>>>>>>>>>
> >>>>>>>>>> This is why the search should accept more then the name.
> >>>>>>>>>> Example (vm=name, disk=name/alias)
> >>>>>>>>>> Example (dc=name, disk=name/alias)
> >>>>>>>>>> Example (sd=name, disk=name/alias)
> >>>>>>>>>
> >>>>>>>>> it's not about accepting both name/alias, it's about
> >>>>>>>>> missing
> >>>>>>>>> ability
> >>>>>>>>> to identify your resource in collection.
> >>>>>>>>>
> >>>>>>>>>> For floating/shared on the same SD/DC/VM I would suggest a
> >>>>>>>>>> warning
> >>>>>>>>>> if there is a duplicate in the system - not enforcement.
> >>>>>>>>>
> >>>>>>>>> ok, lets assume we WARN user that his disk's name is not
> >>>>>>>>> unique,
> >>>>>>>>> how
> >>>>>>>>> user will pick the unique name?
> >>>>>>>>> implementing own code checking if new name (he wants to
> >>>>>>>>> use)
> >>>>>>>>> is
> >>>>>>>>> unique or not?
> >>>>>>>>>
> >>>>>>>>> - this is business logic, not user's prerogative.
> >>>>>>>>>
> >>>>>>>>>> There is a difference between best practice and being
> >>>>>>>>>> enforcing
> >>>>>>>>>> up
> >>>>>>>>>> to the level that it annoys some of the users.
> >>>>>>>>>
> >>>>>>>>> simon, when you register to email, you have to try N times
> >>>>>>>>> till
> >>>>>>>>> you
> >>>>>>>>> find unique username,
> >>>>>>>>> is it convenient? absolutely NO, is it annoying? YES, but
> >>>>>>>>> you
> >>>>>>>>> forced
> >>>>>>>>> doing that so
> >>>>>>>>> system will be able to identify you,
> >>>>>>>>>
> >>>>>>>>> it's no different in any way, good software protects
> >>>>>>>>> user/itself
> >>>>>>>>> even
> >>>>>>>>> in cost of convenience,
> >>>>>>>>>
> >>>>>>>>> bottom line
> >>>>>>>>> ===========
> >>>>>>>>>
> >>>>>>>>> - i think as long as disk not shared/floating it can have
> >>>>>>>>> any
> >>>>>>>>> name
> >>>>>>>>> - in a minute disk designation changed to shared, name
> >>>>>>>>> uniqueness
> >>>>>>>>> should be forced (by the engine)
> >>>>>>>>> - when importing vm with shared disks, name uniqueness
> >>>>>>>>> should
> >>>>>>>>> be
> >>>>>>>>> forced
> >>>>>>>>> - when creating vm from template with shared disk, name
> >>>>>>>>> uniqueness
> >>>>>>>>> should be forced
> >>>>>>>>> - alias should be changed back to name (in sake of
> >>>>>>>>> consistency)
> >>>>>>>>> - /api/disks collection should support searching disks by
> >>>>>>>>> name
> >>>>>>>>> (in
> >>>>>>>>> sake of consistency)
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> thoughts?
> >>>>>>>>
> >>>>>>>> Please look at the previous comment, that just can't work in
> >>>>>>>> the
> >>>>>>>> multi-tenancy case.
> >>>>>>>> Name should not be unique, the warning is for the admin
> >>>>>>>> only,
> >>>>>>>> from
> >>>>>>>> the user portal a warning should be issues only if the user
> >>>>>>>> provides
> >>>>>>>> same name twice.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> --
> >>>>>>>>>>>
> >>>>>>>>>>> Michael Pasternak
> >>>>>>>>>>> RedHat, ENG-Virtualization R&D
> >>>>>>>>>>> _______________________________________________
> >>>>>>>>>>> Engine-devel mailing list
> >>>>>>>>>>> Engine-devel at ovirt.org
> >>>>>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>>
> >>>>>>>>> Michael Pasternak
> >>>>>>>>> RedHat, ENG-Virtualization R&D
> >>>>>>>>> _______________________________________________
> >>>>>>>>> Engine-devel mailing list
> >>>>>>>>> Engine-devel at ovirt.org
> >>>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>>>>>>>>
> >>>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> Engine-devel mailing list
> >>>>>>> Engine-devel at ovirt.org
> >>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>>>>>
> >>>>
> >>> _______________________________________________
> >>> Engine-devel mailing list
> >>> Engine-devel at ovirt.org
> >>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>>
> >>
> >>
> >> _______________________________________________
> >> Engine-devel mailing list
> >> Engine-devel at ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>
> 
> 
> 


From mpastern at redhat.com  Thu Oct 25 15:47:36 2012
From: mpastern at redhat.com (Michael Pasternak)
Date: Thu, 25 Oct 2012 17:47:36 +0200
Subject: [Engine-devel] alias in disk instead of name
In-Reply-To: <1638221000.5207513.1351015665244.JavaMail.root@redhat.com>
References: <1638221000.5207513.1351015665244.JavaMail.root@redhat.com>
Message-ID: <50895F18.1090707@redhat.com>

On 10/23/2012 08:07 PM, Simon Grinberg wrote:
> 
> ----- Original Message -----
>> > From: "Charlie" <medievalist at gmail.com>
>> > To: "Simon Grinberg" <simon at redhat.com>
>> > Cc: "engine-devel" <engine-devel at ovirt.org>
>> > Sent: Tuesday, October 23, 2012 7:53:10 PM
>> > Subject: Re: [Engine-devel] alias in disk instead of name
>> > 
>> > Why not something like this?
>> > 
>> > (pseudocode, using dot for string concatenation):
>> > 
>> > $name_prefix = "vmdrive"
>> > $name = get_last_used($name_prefix)
>> > $already_in_use = $TRUE
>> > 
>> > while $already_in_use {
>> >      prompt "Name of thing? [$name] ", $name
>> >      if name_used($name) {
>> >          while name_used($name) {
>> >             increment_number($name)
>> >          }
>> >      } else {
>> >          $already_in_use = FALSE
>> >      }
>> > }
>> > 
>> > do_whatever_you_do_with($name)
>> > 
>> > store_last_used($name)
>> > 
>> > end
>> > 
>> > 
>> > The increment_number() routine checks to see if the last character is
>> > numeric, and if it is, increments the leftmost contiguous numeric
>> > portion of the string.  Otherwise it appends the number zero.
>> > 
>> > This does not allow everyone to get any name they want, but you can't
>> > ever satisfy that demand.  It supplies reasonable defaults very
>> > quickly and it allows people who want really descriptive names to try
>> > as many as they like.
>> > 
>> > The code's built the funny way it is so that you can corrupt the db
>> > that holds the last_used numbers or interrupt the process halfway
>> > through and it still works, only slower, and it should tend to fix
>> > its
>> > own db on the fly when possible.
>> > 
>> > There's no provision for simultaneous creation, but that wouldn't be
>> > horribly hard to add, just put a lock on the resource holding
>> > last_used numbers.
>> > 
>> > You'd want to reimplement in the most efficient and readable way for
>> > your programming language of choice.
>> > 
>> > Did that make any sense?  I did it off the top of my head, so it
>> > could
>> > be terribly lame when I look at it tomorrow ;).
> Please don't look at it as pure programming item, nor as a single user in a small data center - in this respect you are right.
> Let's got to a huge organization or to the cloud.
> 
> In multi tenant environment this lock means that every time a user tries to change a disk name - all the others are stack
> Don't forget we are discussing thousands of VMs - I'll hate to have this kind of lock just to allow for unique disk names. This is one of the reasons you use UUID to really identify the object in the DB, since it's suppose to guarantee uniqueness without the need to lock everything.

ID available in api, but not in UI, as you told there can be thousands of disks,
and if N of them will share same alias, admin simply won't be able identifying own disk.


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From agl at us.ibm.com  Thu Oct 25 15:53:37 2012
From: agl at us.ibm.com (Adam Litke)
Date: Thu, 25 Oct 2012 10:53:37 -0500
Subject: [Engine-devel] New component 'mom' added to Bugzilla
Message-ID: <20121025155337.GL3672@aglitke>

Hi all,

MOM is becoming a bigger part of oVirt and unfortunately it may have bugs at
some point :(  Thanks to Yaniv we have a new 'mom' component in oVirt's bugzilla
where you can report these.

To file a new bug against MOM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=oVirt;component=mom

Thanks!

-- 
Adam Litke <agl at us.ibm.com>
IBM Linux Technology Center



From abaron at redhat.com  Sat Oct 27 16:13:59 2012
From: abaron at redhat.com (Ayal Baron)
Date: Sat, 27 Oct 2012 18:13:59 +0200
Subject: [Engine-devel] [vdsm] unmanaged devices thrown into 'custom'
 feature
In-Reply-To: <5087668B.6050708@redhat.com>
References: <2094921670.872190.1351025555185.JavaMail.root@redhat.com>
	<5087668B.6050708@redhat.com>
Message-ID: <508C0847.8040603@redhat.com>

On 10/24/2012 05:54 AM, Itamar Heim wrote:
> On 10/23/2012 10:52 PM, Ayal Baron wrote:
>>
>>
>> ----- Original Message -----
>>> On Tue, Oct 23, 2012 at 05:53:20AM -0400, Doron Fediuck wrote:
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: "Livnat Peer" <lpeer at redhat.com>
>>>>> To: "Dan Kenigsberg" <danken at redhat.com>
>>>>> Cc: engine-devel at ovirt.org, "Genadi Chereshnya"
>>>>> <gcheresh at redhat.com>, vdsm-devel at fedorahosted.org
>>>>> Sent: Monday, October 22, 2012 8:29:20 AM
>>>>> Subject: Re: [Engine-devel] [vdsm] unmanaged devices thrown into
>>>>> 'custom' feature
>>>>>
>>>>> On 21/10/12 23:49, Dan Kenigsberg wrote:
>>>>>> On Sun, Oct 21, 2012 at 11:57:10AM -0400, Eli Mesika wrote:
>>>>>>>
>>>>>>>
>>>>>>> ----- Original Message -----
>>>>>>>> From: "Yair Zaslavsky" <yzaslavs at redhat.com>
>>>>>>>> To: "Livnat Peer" <lpeer at redhat.com>
>>>>>>>> Cc: "Genadi Chereshnya" <gcheresh at redhat.com>,
>>>>>>>> engine-devel at ovirt.org, vdsm-devel at fedorahosted.org
>>>>>>>> Sent: Sunday, October 21, 2012 5:38:54 PM
>>>>>>>> Subject: Re: [Engine-devel] unmanaged devices thrown into
>>>>>>>> 'custom' feature
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ----- Original Message -----
>>>>>>>>> From: "Livnat Peer" <lpeer at redhat.com>
>>>>>>>>> To: "Dan Kenigsberg" <danken at redhat.com>
>>>>>>>>> Cc: "Genadi Chereshnya" <gcheresh at redhat.com>,
>>>>>>>>> engine-devel at ovirt.org, vdsm-devel at fedorahosted.org
>>>>>>>>> Sent: Sunday, October 21, 2012 5:18:31 PM
>>>>>>>>> Subject: Re: [Engine-devel] unmanaged devices thrown into
>>>>>>>>> 'custom'
>>>>>>>>> feature
>>>>>>>>>
>>>>>>>>> On 21/10/12 16:42, Dan Kenigsberg wrote:
>>>>>>>>>> I have just noticed that when a VM is started for the
>>>>>>>>>> second
>>>>>>>>>> time,
>>>>>>>>>> Engine
>>>>>>>>>> issues the "create" vdsm verb with some information
>>>>>>>>>> regarding
>>>>>>>>>> "unmanaged" devices (an example is shown below[1]) in the
>>>>>>>>>> 'custom'
>>>>>>>>>> propery bag.
>>>>>>>>>>
>>>>>>>>>> I'm surprised about this, as I was not aware of this usage
>>>>>>>>>> of
>>>>>>>>>> the
>>>>>>>>>> 'custom' dictionary, and Vdsm is not doing anything with
>>>>>>>>>> the
>>>>>>>>>> data.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> If I recall correctly the idea of passing the unmanaged
>>>>>>>>> devices
>>>>>>>>> data
>>>>>>>>> in
>>>>>>>>> the custom property was to enable managing stable device
>>>>>>>>> addresses
>>>>>>>>> in
>>>>>>>>> the hooks (to devices that were added to the VM via hooks
>>>>>>>>> from
>>>>>>>>> the
>>>>>>>>> first
>>>>>>>>> place), so this info is there not for VDSM use.
>>>>>>>>> For example if you add a device in a hook it will be kept in
>>>>>>>>> the
>>>>>>>>> engine
>>>>>>>>> as a non managed device. later when starting the VM again
>>>>>>>>> you
>>>>>>>>> would
>>>>>>>>> like
>>>>>>>>> to assign the same device address to your device, and you
>>>>>>>>> can do
>>>>>>>>> so
>>>>>>>>> because you have access to the original address in the
>>>>>>>>> custom
>>>>>>>>> properties
>>>>>>>>> of the VM.
>>>>>>>>
>>>>>>>> This is exactly what Eli has explained Gendai and Dan today.
>>>>>>
>>>>>> (I was asking here because I did not understand the verbal
>>>>>> explanation.)
>>>>>>
>>>>>>>
>>>>>>> This is taken from the Stable Device Address design in
>>>>>>> http://wiki.ovirt.org/wiki/Features/Design/StableDeviceAddresses
>>>>>>>
>>>>>>> Unmanaged Device
>>>>>>> -----------------
>>>>>>> Unmanaged Device will be supported in the new format and will
>>>>>>> include all unhandled devices as sound/controller/etc and
>>>>>>> future
>>>>>>> devices. Those devices will be persistent and will have Type ,
>>>>>>> SubType (device specific) and an Address. For 3.1 an unmanaged
>>>>>>> Device is not exposed to any GUI/REST API. Unmanaged devices
>>>>>>> are
>>>>>>> passed to vdsm inside a Custom property. VDSM in it turn is
>>>>>>> passing this as is for possible hook processing.
>>>>>>
>>>>>> Thanks for the elaboration. Too bad that I've missed this issue
>>>>>> before.
>>>>>>
>>>>>> Are you aware of any hook making use of this?  I hope that hook
>>>>>> writers
>>>>>> are not using APIs that are not documented in vdsmd(8).
>>>>>>
>>>>>> It seems as a classic case where a generic bag interface is
>>>>>> coerced
>>>>>> into
>>>>>> an awkward partially-documented interface.
>>>>>>
>>>>>> I think that a better approach would have been to pass all
>>>>>> devices
>>>>>> (managed and unmanaged alike) in the 'devices' property, and
>>>>>> let
>>>>>> vdsm
>>>>>> expose whatever is needed to the before_vm_start hook.
>>>>>>
>>>>>> Maybe we can still do this.
>>>>>
>>>>> That was the original idea but Ayal objected and I think Igor did
>>>>> not
>>>>> like it as well...
>>>>>
>>>>
>>>> +2.
>>>> The original design had an 'unmanaged' (or generic) device type,
>>>> and all
>>>> devices should have been normalized. But as explained, this was
>>>> strongly
>>>> rejected in the VDSM side, causing Eli write some special handling
>>>> for this anomaly.
>>>
>>> Can someone (Ayal?) explain the rejection on Vdsm side?
>>> Hiding part of the API in the custom propery bag requires strong
>>> reasoning indeed.
>>
>> It's not hiding anything.
>> Today vdsm passes the libvirt xml to the hooks + the custom properties.
>> If you pass 'non-managed devices' through the devices API then 
>> basically you're saying to vdsm 'here is a bunch of things I want you 
>> to ignore but be a sport and pass it on to the hooks'.
>> Last I checked, that mechanism is custom properties.  I don't see any 
>> reason to add another one.
>
> 1. this means hooks don't actually get the unmanaged devices today?

Yes they do, in the custom properties.

> 2. custom property are to pass parameters to the hook user can 
> reasonably control. device management should not be part of that if 
> not strictly related to the hook (from user's side).

No problem, then we should not pass these devices at all.

> 3. I'm guessing (didn't get this first time i read your answer), you 
> are hinting the unmanaged devices should be passed as a custom 
> property to vdsm, auto generated by engine?
I'm not saying this is what *should* happen, I'm saying this is what 
*is* happening.
vdsm passes to hooks 2 things:
1. libvirt xml (which obviously would not contain 'unmanaged devices')
2. whatever is passed in 'custom properties' by engine (afaik engine 
passes the entire bag of properties to all hooks, relevant or not).
For some reason someone insisted on being able to pass all the devices 
engine gets back from the vm back to the hooks even if these were not 
passed by engine when starting up the VM (iirc the idea was that if a 
hook adds a device in this way it is able to know what address the 
device got on previous run and maintain stable device addresses).
What I opposed originally was the ability when running a VM to pass in 
the devices section a list of devices that should not be attached to the 
vm (i.e. 'here is a list of devices that I don't want you to use devices 
in the vm').  I think it's self evident why I was against this and why I 
still oppose the idea.
If you want a bag of rubbish to pass to hooks then that is 'custom 
properties'.  No need to make the API any uglier.
Personally, I think that any hook that adds devices should be able to 
manage addresses (e.g. choose an empty address, or add a post hook for 
running VMs and persist the info).
In fact, this is just another case where hooks are used in the entirely 
wrong place.  The place to do this is in the engine with an engine side 
pre-run vm hook and then any devices you want to add to the VM become 
'managed' as far as vdsm is concerned.

Note that from what I could understand, Dan was really trying to 
understand why we don't 'manage' these devices (actually passing them to 
libvirt on subsequent runs of the VM).




From lhornyak at redhat.com  Mon Oct 29 15:40:28 2012
From: lhornyak at redhat.com (Laszlo Hornyak)
Date: Mon, 29 Oct 2012 11:40:28 -0400 (EDT)
Subject: [Engine-devel] ovirt on wikipedia
In-Reply-To: <1092666208.400735.1351520313102.JavaMail.root@redhat.com>
Message-ID: <165147602.449665.1351525228071.JavaMail.root@redhat.com>

Hi,

http://en.wikipedia.org/wiki/OVirt
At the moment there are OVirt pages in english, russian and hungarian.
Any volunteers to write czech, hebrew, german, spanish, catalan? - just to mention the languages some ovirt-developers speak :-)

Laszlo


From asegurap at redhat.com  Mon Oct 29 18:03:48 2012
From: asegurap at redhat.com (Antoni Segura Puimedon)
Date: Mon, 29 Oct 2012 14:03:48 -0400 (EDT)
Subject: [Engine-devel] ovirt on wikipedia
In-Reply-To: <165147602.449665.1351525228071.JavaMail.root@redhat.com>
Message-ID: <1415514502.6068050.1351533828684.JavaMail.root@redhat.com>

Very good idea Laszlo. I'll get to it as soon as I can.

----- Original Message -----
> From: "Laszlo Hornyak" <lhornyak at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>
> Sent: Monday, October 29, 2012 4:40:28 PM
> Subject: [Engine-devel] ovirt on wikipedia
> 
> Hi,
> 
> http://en.wikipedia.org/wiki/OVirt
> At the moment there are OVirt pages in english, russian and
> hungarian.
> Any volunteers to write czech, hebrew, german, spanish, catalan? -
> just to mention the languages some ovirt-developers speak :-)
> 
> Laszlo
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From deepakcs at linux.vnet.ibm.com  Tue Oct 30 05:44:42 2012
From: deepakcs at linux.vnet.ibm.com (Deepak C Shetty)
Date: Tue, 30 Oct 2012 11:14:42 +0530
Subject: [Engine-devel] ovirt on wikipedia
In-Reply-To: <165147602.449665.1351525228071.JavaMail.root@redhat.com>
References: <165147602.449665.1351525228071.JavaMail.root@redhat.com>
Message-ID: <508F694A.4010200@linux.vnet.ibm.com>

Very nice, i did a minor grammatical edit

 >as it the base for Red Hat Enterprise Virtualization 
<http://en.wikipedia.org/wiki/Red_Hat_Enterprise_Virtualization>.
and it is the base for Red Hat Enterprise Virtualization 
<http://en.wikipedia.org/wiki/Red_Hat_Enterprise_Virtualization>.

Also it would be good if the URL shows up as

http://en.wikipedia.org/wiki/oVirt
instead of OVirt

I was not able to figure how to do that.



On 10/29/2012 09:10 PM, Laszlo Hornyak wrote:
> Hi,
>
> http://en.wikipedia.org/wiki/OVirt
> At the moment there are OVirt pages in english, russian and hungarian.
> Any volunteers to write czech, hebrew, german, spanish, catalan? - just to mention the languages some ovirt-developers speak :-)
>
> Laszlo
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20121030/393af2bf/attachment.html>

From derekh at redhat.com  Tue Oct 30 09:16:09 2012
From: derekh at redhat.com (Derek Higgins)
Date: Tue, 30 Oct 2012 09:16:09 +0000
Subject: [Engine-devel] Splitting out the oVirt engine installer
In-Reply-To: <239053036.5048520.1350983598957.JavaMail.root@redhat.com>
References: <239053036.5048520.1350983598957.JavaMail.root@redhat.com>
Message-ID: <508F9AD9.5070309@redhat.com>

Hi Alon,
    thanks for the info on this, I was out of the office last week but
I'll take a look at it this week and get back to you.

thanks,
Derek.

On 10/23/2012 10:13 AM, Alon Bar-Lev wrote:
> 
> 
> ----- Original Message -----
>> From: "Derek Higgins" <derekh at redhat.com>
>> To: engine-devel at ovirt.org
>> Sent: Sunday, September 23, 2012 11:36:48 PM
>> Subject: [Engine-devel] Splitting out the oVirt engine installer
>>
>> Hi All,
>>     First time poster here so let me know if this is better directed
>> some where else
>>
>>     I have been writing a installer for openstack and as a base for
>>     this
>> I've split out the generic parts of your engine-setup utility[1].
>> In order to do this I've created a generic installer[2] that is
>> basically all of the parts of the oVirt engine installer that I
>> needed
>> for my openstack installer[3]
>>
>> I'd now like to see if there is interest here to use this generic
>> installer for oVirt.
>>
>> I may have stripped out some stuff from the installer that I should
>> have
>> left in, if that is the case I'm open to recreating this repository
>> with
>> anything generic I shouldn't have stripped out so that the original
>> history is maintained. Would anybody here like to look into the work
>> necessary to use this installer in oVirt? For openstack I've made
>> exclusive use of the plugin functionality and I suspect most changes
>> that would be needed for oVirt would be to move a lot of the code
>> into a
>> similar pattern.
>>
>> If you have any questions/comments just let me know, hopefully you
>> will
>> find this useful and other projects could make use of the great work
>> you
>> have done developing this setup utility
>>
>> Thanks,
>> Derek.
>>
>> [1]
>> https://github.com/derekhiggins/ovirt-engine/tree/master/packaging/fedora/setup
>> [2] https://github.com/derekhiggins/installer
>> [3] https://github.com/derekhiggins/os-installer
> 
> Hello Derek,
> 
> I re-wrote the vdsm-bootstrap, it was very complex and contained much legacy.
> 
> It turned out that the vdsm-bootstrap and the engine-setup/engine-upgrade has a lot in common.
> 
> So it is actually a base to any installer.
> 
> In short:
> ---
> It is fully plugin, task oriented implementation.
> Compatible with python-2.6, python-2.7, python-3.2
> Fully localized enabled.
> Single session interaction, no file transfer.
> Local and remote execution modes are supported.
> Distribution independent implementation (core).
> ---
> 
> The mission is to make it easy as much as possible to add new functionality without the complexity of the state and transaction management. If you look at the plugins directories, you will find the business logic, which is about 98% pure.
> 
> At the core of the implementation there is environment dictionary and a flow of stages within plugins. The environment can be modified using command-line parameters, configuration file, or dialog customization.
> 
> At the bottom of this message there is a sample of the dialog between manager and installer.
> 
> Although not 100% complete, I will be happy to receive any comment, suggestion and rejections.
> 
> A snapshot of development sources are available at[1].
> 
> I will be happy to receive your feedback!
> 
> Best Regards,
> Alon Bar-Lev.
> 
> [1] https://github.com/alonbl/ovirt-installer
> 



From shaohef at linux.vnet.ibm.com  Tue Oct 30 10:02:51 2012
From: shaohef at linux.vnet.ibm.com (Sheldon)
Date: Tue, 30 Oct 2012 18:02:51 +0800
Subject: [Engine-devel] [help]how to get the CA certificate when uploader ISO
Message-ID: <508FA5CB.8040504@linux.vnet.ibm.com>

error when I update a iso to iso domain by engine-iso-uploader
# engine-iso-uploader --iso-domain=ISO upload Fedora-17-x86_64-DVD.iso
Please provide the REST API password for the admin at internal oVirt Engine 
user (CTRL+D to abort):
ERROR: [ERROR]::ca_file (CA certificate) must be specified for SSL 
connection.
INFO: Use the -h option to see usage.

but I manual engine-iso-uploader, there is no any information about 
certificate.
# man engine-iso-uploader

-- 
Sheldon Feng(???)<shaohef at linux.vnet.ibm.com>
IBM Linux Technology Center



From kroberts at redhat.com  Tue Oct 30 10:08:13 2012
From: kroberts at redhat.com (Keith Robertson)
Date: Tue, 30 Oct 2012 06:08:13 -0400
Subject: [Engine-devel] [help]how to get the CA certificate when
 uploader ISO
In-Reply-To: <508FA5CB.8040504@linux.vnet.ibm.com>
References: <508FA5CB.8040504@linux.vnet.ibm.com>
Message-ID: <508FA70D.1010802@redhat.com>

On 10/30/2012 06:02 AM, Sheldon wrote:
> error when I update a iso to iso domain by engine-iso-uploader
> # engine-iso-uploader --iso-domain=ISO upload Fedora-17-x86_64-DVD.iso
> Please provide the REST API password for the admin at internal oVirt 
> Engine user (CTRL+D to abort):
> ERROR: [ERROR]::ca_file (CA certificate) must be specified for SSL 
> connection.
> INFO: Use the -h option to see usage.
>
> but I manual engine-iso-uploader, there is no any information about 
> certificate.
> # man engine-iso-uploader
>
The LC needs to be rebuilt.  The code in the GIT repo has the patch but 
it isn't in the official download spot.  In the meantime you can roll 
your own with [1].

In the future, the tools need to become part of the nightly builds.


[1]
Step 1: git clone http://gerrit.ovirt.org/p/ovirt-iso-uploader.git
Step 2: export APP_VERSION=3.0.0; export APP_RELEASE=1
Step 3: cd ovirt-iso-uploader
Step 4: make
Step 5: Notice the ovirt-iso-uploader*.rpm location in the STDOUT
Step 6: yum install /path/to/ovirt-iso-uploader*.rpm


From shaohef at linux.vnet.ibm.com  Tue Oct 30 11:13:11 2012
From: shaohef at linux.vnet.ibm.com (Sheldon)
Date: Tue, 30 Oct 2012 19:13:11 +0800
Subject: [Engine-devel] [help]how to get the CA certificate when
 uploader ISO
In-Reply-To: <508FA70D.1010802@redhat.com>
References: <508FA5CB.8040504@linux.vnet.ibm.com> <508FA70D.1010802@redhat.com>
Message-ID: <508FB647.9020002@linux.vnet.ibm.com>

On 10/30/2012 06:08 PM, Keith Robertson wrote:
> On 10/30/2012 06:02 AM, Sheldon wrote:
>> error when I update a iso to iso domain by engine-iso-uploader
>> # engine-iso-uploader --iso-domain=ISO upload Fedora-17-x86_64-DVD.iso
>> Please provide the REST API password for the admin at internal oVirt 
>> Engine user (CTRL+D to abort):
>> ERROR: [ERROR]::ca_file (CA certificate) must be specified for SSL 
>> connection.
>> INFO: Use the -h option to see usage.
>>
>> but I manual engine-iso-uploader, there is no any information about 
>> certificate.
>> # man engine-iso-uploader
>>
> The LC needs to be rebuilt.  The code in the GIT repo has the patch 
> but it isn't in the official download spot.  In the meantime you can 
> roll your own with [1].
>
> In the future, the tools need to become part of the nightly builds.
>
>
> [1]
> Step 1: git clone http://gerrit.ovirt.org/p/ovirt-iso-uploader.git
> Step 2: export APP_VERSION=3.0.0; export APP_RELEASE=1
> Step 3: cd ovirt-iso-uploader
> Step 4: make
> Step 5: Notice the ovirt-iso-uploader*.rpm location in the STDOUT
> Step 6: yum install /path/to/ovirt-iso-uploader*.rpm
>

still error, Maybe I should waiting for tools in the nightly builds.
$ sudo rpm -qa | grep iso-uploader
ovirt-iso-uploader-3.0.0-1.fc17.noarch

$ sudo engine-iso-uploader --iso-domain=ISO upload Fedora-17-x86_64-DVD.iso
Please provide the REST API username for oVirt Engine (CTRL+D to abort): 
admin at internal
Please provide the REST API password for the admin at internal oVirt Engine 
user (CTRL+D to abort):
ERROR: Problem connecting to the REST API.  Is the service available and 
does the CA certificate exist?
ERROR: 'NoneType' object is not iterable
INFO: Use the -h option to see usage.

-- 
Sheldon Feng(???)<shaohef at linux.vnet.ibm.com>
IBM Linux Technology Center



From kroberts at redhat.com  Tue Oct 30 12:09:23 2012
From: kroberts at redhat.com (Keith Robertson)
Date: Tue, 30 Oct 2012 08:09:23 -0400
Subject: [Engine-devel] [help]how to get the CA certificate when
 uploader ISO
In-Reply-To: <508FB647.9020002@linux.vnet.ibm.com>
References: <508FA5CB.8040504@linux.vnet.ibm.com> <508FA70D.1010802@redhat.com>
	<508FB647.9020002@linux.vnet.ibm.com>
Message-ID: <508FC373.8080901@redhat.com>

On 10/30/2012 07:13 AM, Sheldon wrote:
> On 10/30/2012 06:08 PM, Keith Robertson wrote:
>> On 10/30/2012 06:02 AM, Sheldon wrote:
>>> error when I update a iso to iso domain by engine-iso-uploader
>>> # engine-iso-uploader --iso-domain=ISO upload Fedora-17-x86_64-DVD.iso
>>> Please provide the REST API password for the admin at internal oVirt 
>>> Engine user (CTRL+D to abort):
>>> ERROR: [ERROR]::ca_file (CA certificate) must be specified for SSL 
>>> connection.
>>> INFO: Use the -h option to see usage.
>>>
>>> but I manual engine-iso-uploader, there is no any information about 
>>> certificate.
>>> # man engine-iso-uploader
>>>
>> The LC needs to be rebuilt.  The code in the GIT repo has the patch 
>> but it isn't in the official download spot.  In the meantime you can 
>> roll your own with [1].
>>
>> In the future, the tools need to become part of the nightly builds.
>>
>>
>> [1]
>> Step 1: git clone http://gerrit.ovirt.org/p/ovirt-iso-uploader.git
>> Step 2: export APP_VERSION=3.0.0; export APP_RELEASE=1
>> Step 3: cd ovirt-iso-uploader
>> Step 4: make
>> Step 5: Notice the ovirt-iso-uploader*.rpm location in the STDOUT
>> Step 6: yum install /path/to/ovirt-iso-uploader*.rpm
>>
>
> still error, Maybe I should waiting for tools in the nightly builds.
> $ sudo rpm -qa | grep iso-uploader
> ovirt-iso-uploader-3.0.0-1.fc17.noarch
>
> $ sudo engine-iso-uploader --iso-domain=ISO upload 
> Fedora-17-x86_64-DVD.iso
> Please provide the REST API username for oVirt Engine (CTRL+D to 
> abort): admin at internal
> Please provide the REST API password for the admin at internal oVirt 
> Engine user (CTRL+D to abort):
> ERROR: Problem connecting to the REST API.  Is the service available 
> and does the CA certificate exist?
> ERROR: 'NoneType' object is not iterable
> INFO: Use the -h option to see usage.
>
Can you re-run with verbose option set?


From shaohef at linux.vnet.ibm.com  Wed Oct 31 05:40:39 2012
From: shaohef at linux.vnet.ibm.com (Sheldon)
Date: Wed, 31 Oct 2012 13:40:39 +0800
Subject: [Engine-devel] [help]how to get the CA certificate when
 uploader ISO
In-Reply-To: <508FC373.8080901@redhat.com>
References: <508FA5CB.8040504@linux.vnet.ibm.com> <508FA70D.1010802@redhat.com>
	<508FB647.9020002@linux.vnet.ibm.com> <508FC373.8080901@redhat.com>
Message-ID: <5090B9D7.8050302@linux.vnet.ibm.com>

On 10/30/2012 08:09 PM, Keith Robertson wrote:
> On 10/30/2012 07:13 AM, Sheldon wrote:
>> On 10/30/2012 06:08 PM, Keith Robertson wrote:
>>> On 10/30/2012 06:02 AM, Sheldon wrote:
>>>> error when I update a iso to iso domain by engine-iso-uploader
>>>> # engine-iso-uploader --iso-domain=ISO upload Fedora-17-x86_64-DVD.iso
>>>> Please provide the REST API password for the admin at internal oVirt 
>>>> Engine user (CTRL+D to abort):
>>>> ERROR: [ERROR]::ca_file (CA certificate) must be specified for SSL 
>>>> connection.
>>>> INFO: Use the -h option to see usage.
>>>>
>>>> but I manual engine-iso-uploader, there is no any information about 
>>>> certificate.
>>>> # man engine-iso-uploader
>>>>
>>> The LC needs to be rebuilt.  The code in the GIT repo has the patch 
>>> but it isn't in the official download spot.  In the meantime you can 
>>> roll your own with [1].
>>>
>>> In the future, the tools need to become part of the nightly builds.
>>>
>>>
>>> [1]
>>> Step 1: git clone http://gerrit.ovirt.org/p/ovirt-iso-uploader.git
>>> Step 2: export APP_VERSION=3.0.0; export APP_RELEASE=1
>>> Step 3: cd ovirt-iso-uploader
>>> Step 4: make
>>> Step 5: Notice the ovirt-iso-uploader*.rpm location in the STDOUT
>>> Step 6: yum install /path/to/ovirt-iso-uploader*.rpm
>>>
>>
>> still error, Maybe I should waiting for tools in the nightly builds.
>> $ sudo rpm -qa | grep iso-uploader
>> ovirt-iso-uploader-3.0.0-1.fc17.noarch
>>
>> $ sudo engine-iso-uploader --iso-domain=ISO upload 
>> Fedora-17-x86_64-DVD.iso
>> Please provide the REST API username for oVirt Engine (CTRL+D to 
>> abort): admin at internal
>> Please provide the REST API password for the admin at internal oVirt 
>> Engine user (CTRL+D to abort):
>> ERROR: Problem connecting to the REST API.  Is the service available 
>> and does the CA certificate exist?
>> ERROR: 'NoneType' object is not iterable
>> INFO: Use the -h option to see usage.
>>
> Can you re-run with verbose option set?
>

I make a domain name "ISO", Domain type is ISO, Storage Type is NFS, 
Format is V1

$ sudo engine-iso-uploader -v --iso-domain=ISO upload 
Fedora-17-x86_64-DVD.iso
[sudo] password for ovirt:
Please provide the REST API username for oVirt Engine (CTRL+D to abort): 
admin at internal
Please provide the REST API password for the admin at internal oVirt Engine 
user (CTRL+D to abort):
ERROR: Problem connecting to the REST API.  Is the service available and 
does the CA certificate exist?
ERROR: 'NoneType' object is not iterable
INFO: Use the -h option to see usage.
DEBUG: Configuration:
DEBUG: command: upload
DEBUG: Traceback (most recent call last):
DEBUG:   File "/bin/engine-iso-uploader", line 956, in <module>
DEBUG:     isoup = ISOUploader(conf)
DEBUG:   File "/bin/engine-iso-uploader", line 334, in __init__
DEBUG:     self.upload_to_storage_domain()
DEBUG:   File "/bin/engine-iso-uploader", line 690, in 
upload_to_storage_domain
DEBUG:     (id, address, path) = 
self.get_host_and_path_from_ISO_domain(self.configuration.get('iso_domain'))
DEBUG: TypeError: 'NoneType' object is not iterable


-- 
Sheldon Feng(???)<shaohef at linux.vnet.ibm.com>
IBM Linux Technology Center



From mskrivan at redhat.com  Wed Oct 31 07:33:35 2012
From: mskrivan at redhat.com (Michal Skrivanek)
Date: Wed, 31 Oct 2012 03:33:35 -0400 (EDT)
Subject: [Engine-devel] ovirt on wikipedia
In-Reply-To: <508F694A.4010200@linux.vnet.ibm.com>
References: <165147602.449665.1351525228071.JavaMail.root@redhat.com>
	<508F694A.4010200@linux.vnet.ibm.com>
Message-ID: <7B8731F2-0FE5-45D5-AA4E-49F2FE4FE550@redhat.com>



On 30 Oct 2012, at 06:48, Deepak C Shetty <deepakcs at linux.vnet.ibm.com> wrote:

> Very nice, i did a minor grammatical edit
> 
> >as it the base for Red Hat Enterprise         Virtualization.
> and it is the base for Red Hat Enterprise Virtualization.
> 
> Also it would be good if the URL shows up as 
> http://en.wikipedia.org/wiki/oVirt
> instead of OVirt
> 
> I was not able to figure how to do that.
It's a WikiWord, first letter needs to be uppercase I believe...
better than Ovirt:)

Thanks,
michal
> 
> 
> On 10/29/2012 09:10 PM, Laszlo Hornyak wrote:
>> Hi,
>> 
>> http://en.wikipedia.org/wiki/OVirt
>> At the moment there are OVirt pages in english, russian and hungarian.
>> Any volunteers to write czech, hebrew, german, spanish, catalan? - just to mention the languages some ovirt-developers speak :-)
>> 
>> Laszlo
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>> 
>> 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20121031/dab657c4/attachment.html>

From ykaul at redhat.com  Wed Oct 31 08:04:55 2012
From: ykaul at redhat.com (Yaniv Kaul)
Date: Wed, 31 Oct 2012 10:04:55 +0200
Subject: [Engine-devel] ovirt on wikipedia
In-Reply-To: <165147602.449665.1351525228071.JavaMail.root@redhat.com>
References: <165147602.449665.1351525228071.JavaMail.root@redhat.com>
Message-ID: <5090DBA7.6090808@redhat.com>

On 10/29/2012 05:40 PM, Laszlo Hornyak wrote:
> Hi,
>
> http://en.wikipedia.org/wiki/OVirt
> At the moment there are OVirt pages in english, russian and hungarian.
> Any volunteers to write czech, hebrew, german, spanish, catalan? - just to mention the languages some ovirt-developers speak :-)
>
> Laszlo
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel

While I could have translated it to Hebrew, I thought it might be more 
productive to beef-up the English content.
I've added information on networking, frontends and API. Once I get how 
to edit with table of contents, I'll split to:
release history
components
features

Y.



From dneary at redhat.com  Wed Oct 31 09:20:34 2012
From: dneary at redhat.com (Dave Neary)
Date: Wed, 31 Oct 2012 10:20:34 +0100
Subject: [Engine-devel] ovirt on wikipedia
In-Reply-To: <7B8731F2-0FE5-45D5-AA4E-49F2FE4FE550@redhat.com>
References: <165147602.449665.1351525228071.JavaMail.root@redhat.com>
	<508F694A.4010200@linux.vnet.ibm.com>
	<7B8731F2-0FE5-45D5-AA4E-49F2FE4FE550@redhat.com>
Message-ID: <5090ED62.4060305@redhat.com>

Hi,

On 10/31/2012 08:33 AM, Michal Skrivanek wrote:
>> Also it would be good if the URL shows up as
>> http://en.wikipedia.org/wiki/oVirt
>> instead of OVirt
>>
>> I was not able to figure how to do that.
> It's a WikiWord, first letter needs to be uppercase I believe...
> better than Ovirt:)

You can at least get the word to display as oVirt in the page title by 
adding
{{lowercase title}}
to the top of the page: 
http://en.wikipedia.org/wiki/Wikipedia:Naming_conventions_%28technical_restrictions%29#Lower_case_first_letter

Cheers,
Dave.

-- 
Dave Neary
Community Action and Impact
Open Source and Standards, Red Hat
Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13


From plysab at gmail.com  Wed Oct 31 10:32:48 2012
From: plysab at gmail.com (ly pan)
Date: Wed, 31 Oct 2012 18:32:48 +0800
Subject: [Engine-devel] Question about hasMemoryToRunVM() in
	RunVmCommandBase
In-Reply-To: <1076764376.16688374.1351076786318.JavaMail.root@redhat.com>
References: <CANDY9WNP77dtoMqUa9qokRUDsM+K5=WYzuYav_yCgbWXEhXF2Q@mail.gmail.com>
	<1076764376.16688374.1351076786318.JavaMail.root@redhat.com>
Message-ID: <CANDY9WNz4h=S9zoqRTm8iFmqJO=qk6CjZodSov6TEZUXCZfYuA@mail.gmail.com>

Hi Doron,

Sorry for the so late reply.
These days I looked into the code again and found it's my setting not
rightly configured.
1. You opinion about reserved_mem is right.
2. Yes, pending_vmem_size is 0 before the 84th runs.
3. memory_over_commit is where my problem is.

In webadmin UI, I set the cluster's memory optimization
to none, thus memory_over_commit is 100 in DB(the dafault value is 100
in my env).
when I set the cluster's mem_opt to 'for server load',
memory_over_commit grows to 150
and when I set to 'for desktop load', memory_over_commit grows to 200.

Both 'for server load' and 'for desktop load' have let the vdsMemLimit
grows dramaticaly,
thus the 84th vm managed to run.
So I realized the memory optimization option in cluster is for KSM function.

Thank you.

ly pan


2012/10/24 Doron Fediuck <dfediuck at redhat.com>:
> ----- Original Message -----
>> From: "ly pan" <plysab at gmail.com>
>> To: engine-devel at ovirt.org
>> Sent: Thursday, October 18, 2012 2:43:35 PM
>> Subject: [Engine-devel] Question about hasMemoryToRunVM() in RunVmCommandBase
>>
>> Hi:
>>
>> This is my test environment:
>> hardware: Dell PowerEdge 2710 ,Memory 48G
>> Software: OVirt engine 3.0 ,VDSM 4.9.4 ,kernel
>> 2.6.32-279.2.1.el6.x86_64
>>
>>
>> I create 100 vms from pool(each vm has 512M memory and has
>> 1M memory garanteed, with guest_overhead = 65 and reserved_mem =
>> 256),
>> but only 83 vms
>> turn out to run. When I run the 84th vm, engine says there is not
>> enough memory. However at this time KSM is enabled and 15G free
>> memory
>> is still left on the host.
>>
>> I checked the code and found out that before running a vm, the
>> function hasMemoryToRunVM() in RunVmCommandBase would decide whether
>> there is enough memory in the selected host to run it.
>> The Algorithm in the function is like this:
>> mem_avaliable >= mem_required = curVds.getmem_commited() +
>> curVds.getpending_vmem_size()
>>      + curVds.getguest_overhead() + curVds.getreserved_mem() +
>> vm.getMinAllocatedMem();
>>
>> And here is my question: curVds.getmem_commited() is caculated from
>> the memory of vm
>> assigned by user. But when the host is running with KSM enabled, the
>> actual memory of each
>> running vm would be smaller than the memory the user assigned to. In
>> this case, the following
>> may occur: engine says there be no more memroy to run any vm while
>> the
>> host has much free
>> space to run more vms(in my case, 15G).
>>
>>
>> Therefore I think the actual memory size reported by vdsm(The KSM
>> shared memory) should be taken into account when calculating
>> curVds.getmem_commited(). Any ideas are welcome.
>
> Hi Ly,
> Sorry for the delay. I'd like to look into this issue.
> In the meanwhile a few relevant points;
>
> 1. You're saying that reserved_mem=256. This is not accurate, since it's
> reported by vds as host_mem_reserve(256) + extra_mem_reserve(65) = 321
>
> 2. I'm assuming you retried running the 84th vm, just to make sure your
> pending_vmem_size is 0 once all 83 VMs are running.
>
> 3. So assuming (2) is correct, I'd like to ask what's the max_vds_memory_over_commit
> you have for the cluster? By default it's set to 120, and in such a case the 84th
> VM should still be running.
>
> Here's a calculation sample based on your data, and the above 3 issues:
>
> vdsCurrentMem =
> 83 * (512M+65) = 47,891
> 0
> 65
> 321
> 1
> =======
> 48,278
>
> vdsMemLimit =
> 120/100
> *
> 47,321.1328125  // reported by vdsm: 'cat /proc/meminfo | grep MemTotal' / 1024
> =========
> 56,785.359375
>
> So vdsCurrentMem <= vdsMemLimit should be true unless you changed something
> such as the MemTotal or the memory_over_commit. You can try and change memory_over_commit
> let us know how it works.
>
> Doron


From kroberts at redhat.com  Wed Oct 31 13:37:06 2012
From: kroberts at redhat.com (Keith Robertson)
Date: Wed, 31 Oct 2012 09:37:06 -0400
Subject: [Engine-devel] [help]how to get the CA certificate when
 uploader ISO
In-Reply-To: <5090B9D7.8050302@linux.vnet.ibm.com>
References: <508FA5CB.8040504@linux.vnet.ibm.com> <508FA70D.1010802@redhat.com>
	<508FB647.9020002@linux.vnet.ibm.com> <508FC373.8080901@redhat.com>
	<5090B9D7.8050302@linux.vnet.ibm.com>
Message-ID: <50912982.5000606@redhat.com>

On 10/31/2012 01:40 AM, Sheldon wrote:
> I make a domain name "ISO", Domain type is ISO, Storage Type is NFS, 
> Format is V1
>
> $ sudo engine-iso-uploader -v --iso-domain=ISO upload 
> Fedora-17-x86_64-DVD.iso
> [sudo] password for ovirt:
> Please provide the REST API username for oVirt Engine (CTRL+D to 
> abort): admin at internal
> Please provide the REST API password for the admin at internal oVirt 
> Engine user (CTRL+D to abort):
> ERROR: Problem connecting to the REST API.  Is the service available 
> and does the CA certificate exist?
> ERROR: 'NoneType' object is not iterable
> INFO: Use the -h option to see usage. 

Just to be clear the error in [1] is simply a symptom.  It isn't the 
root cause.  The root cause is quite possibly the CA certificate.

I have created a patch in [2] that I'd appreciate if you could test as 
it will provide more debugging information about why the API creation is 
failing.  Simply follow the steps in [3]

Cheers,
Keith

[1] ERROR: 'NoneType' object is not iterable
[2] http://gerrit.ovirt.org/8954
[3]
Step 1: git clone http://gerrit.ovirt.org/p/ovirt-iso-uploader.git
Step 2: Cherry pick the patch...
git fetch git://gerrit.ovirt.org/ovirt-iso-uploader 
refs/changes/54/8954/2 && git cherry-pick FETCH_HEAD
Step 3: export APP_VERSION=3.0.0; export APP_RELEASE=1
Step 4: cd ovirt-iso-uploader
Step 5: make
Step 6: Notice the ovirt-iso-uploader*.rpm location in the STDOUT
Step 7: yum install /path/to/ovirt-iso-uploader*.rpm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20121031/4a01abbc/attachment.html>

From dfediuck at redhat.com  Wed Oct 31 15:27:52 2012
From: dfediuck at redhat.com (Doron Fediuck)
Date: Wed, 31 Oct 2012 11:27:52 -0400 (EDT)
Subject: [Engine-devel] Question about hasMemoryToRunVM()
	in	RunVmCommandBase
In-Reply-To: <CANDY9WNz4h=S9zoqRTm8iFmqJO=qk6CjZodSov6TEZUXCZfYuA@mail.gmail.com>
Message-ID: <994869837.19814005.1351697272156.JavaMail.root@redhat.com>

Hi Ly,
So basically just to be clear, indeed memory_over_commit is the solution
for memory over commitment. Changing it enabled you to run the amount of
VMs you need.

----- Original Message -----
> From: "ly pan" <plysab at gmail.com>
> To: "Doron Fediuck" <dfediuck at redhat.com>
> Cc: engine-devel at ovirt.org 
> Sent: Wednesday, October 31, 2012 12:32:48 PM
> Subject: Re: [Engine-devel] Question about hasMemoryToRunVM() in	RunVmCommandBase
> 
> Hi Doron,
> 
> Sorry for the so late reply.
> These days I looked into the code again and found it's my setting not
> rightly configured.
> 1. You opinion about reserved_mem is right.
> 2. Yes, pending_vmem_size is 0 before the 84th runs.
> 3. memory_over_commit is where my problem is.
> 
> In webadmin UI, I set the cluster's memory optimization
> to none, thus memory_over_commit is 100 in DB(the dafault value is
> 100
> in my env).
> when I set the cluster's mem_opt to 'for server load',
> memory_over_commit grows to 150
> and when I set to 'for desktop load', memory_over_commit grows to
> 200.
> 
> Both 'for server load' and 'for desktop load' have let the
> vdsMemLimit
> grows dramaticaly,
> thus the 84th vm managed to run.
> So I realized the memory optimization option in cluster is for KSM
> function.
> 
> Thank you.
> 
> ly pan
> 
> 
> 2012/10/24 Doron Fediuck <dfediuck at redhat.com>:
> > ----- Original Message -----
> >> From: "ly pan" <plysab at gmail.com>
> >> To: engine-devel at ovirt.org
> >> Sent: Thursday, October 18, 2012 2:43:35 PM
> >> Subject: [Engine-devel] Question about hasMemoryToRunVM() in
> >> RunVmCommandBase
> >>
> >> Hi:
> >>
> >> This is my test environment:
> >> hardware: Dell PowerEdge 2710 ,Memory 48G
> >> Software: OVirt engine 3.0 ,VDSM 4.9.4 ,kernel
> >> 2.6.32-279.2.1.el6.x86_64
> >>
> >>
> >> I create 100 vms from pool(each vm has 512M memory and has
> >> 1M memory garanteed, with guest_overhead = 65 and reserved_mem =
> >> 256),
> >> but only 83 vms
> >> turn out to run. When I run the 84th vm, engine says there is not
> >> enough memory. However at this time KSM is enabled and 15G free
> >> memory
> >> is still left on the host.
> >>
> >> I checked the code and found out that before running a vm, the
> >> function hasMemoryToRunVM() in RunVmCommandBase would decide
> >> whether
> >> there is enough memory in the selected host to run it.
> >> The Algorithm in the function is like this:
> >> mem_avaliable >= mem_required = curVds.getmem_commited() +
> >> curVds.getpending_vmem_size()
> >>      + curVds.getguest_overhead() + curVds.getreserved_mem() +
> >> vm.getMinAllocatedMem();
> >>
> >> And here is my question: curVds.getmem_commited() is caculated
> >> from
> >> the memory of vm
> >> assigned by user. But when the host is running with KSM enabled,
> >> the
> >> actual memory of each
> >> running vm would be smaller than the memory the user assigned to.
> >> In
> >> this case, the following
> >> may occur: engine says there be no more memroy to run any vm while
> >> the
> >> host has much free
> >> space to run more vms(in my case, 15G).
> >>
> >>
> >> Therefore I think the actual memory size reported by vdsm(The KSM
> >> shared memory) should be taken into account when calculating
> >> curVds.getmem_commited(). Any ideas are welcome.
> >
> > Hi Ly,
> > Sorry for the delay. I'd like to look into this issue.
> > In the meanwhile a few relevant points;
> >
> > 1. You're saying that reserved_mem=256. This is not accurate, since
> > it's
> > reported by vds as host_mem_reserve(256) + extra_mem_reserve(65) =
> > 321
> >
> > 2. I'm assuming you retried running the 84th vm, just to make sure
> > your
> > pending_vmem_size is 0 once all 83 VMs are running.
> >
> > 3. So assuming (2) is correct, I'd like to ask what's the
> > max_vds_memory_over_commit
> > you have for the cluster? By default it's set to 120, and in such a
> > case the 84th
> > VM should still be running.
> >
> > Here's a calculation sample based on your data, and the above 3
> > issues:
> >
> > vdsCurrentMem =
> > 83 * (512M+65) = 47,891
> > 0
> > 65
> > 321
> > 1
> > =======
> > 48,278
> >
> > vdsMemLimit =
> > 120/100
> > *
> > 47,321.1328125  // reported by vdsm: 'cat /proc/meminfo | grep
> > MemTotal' / 1024
> > =========
> > 56,785.359375
> >
> > So vdsCurrentMem <= vdsMemLimit should be true unless you changed
> > something
> > such as the MemTotal or the memory_over_commit. You can try and
> > change memory_over_commit
> > let us know how it works.
> >
> > Doron
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>