Re: [ovirt-devel] Gluster Volume Snapshots - Feature review
On 01/01/2015 10:36 PM, Einav Cohen wrote: - Original Message - From: Shubhendu Tripathi shtri...@redhat.com Sent: Thursday, January 1, 2015 10:05:48 AM On 12/31/2014 11:42 PM, Einav Cohen wrote: Thanks, Shubhendu. Additional comments: ... Yes, attempt to create second snapshot schedule is actually an override option. Of course spot creation is allowed in addition to the scheduled. ... ... If the option Volumes - Snapshots - New selected, the dialog opens with pre-populated snapshot name prefix and Recurrence type selected as None by default. This effectively is one time snapshot creation. If this is first time and user wants to schedule the snapshot creation, he/she can change the recurrence type and provide details. Snapshot creation is scheduled in this case. Later, it user wants to edit the schedule, he/she needs to select option Volumes - Snapshots - Schedule (may be for this reason only I want to call it Edit Schedule). So effectively option Volumes - Snapshots - Schedule is meant for only re-scheduling the snapshot creation. If its not yet scheduled dialog opens with recurrence type selected as None. ... From your latest responses, I conclude the following. via the New dialog, you can: (1) create a one-time snapshot (2) create a new snapshot schedule (3) override (and practically, edit) an existing snapshot schedule via the Schedule dialog, you can: (a) create a one-time snapshot (by selecting the 'None' recurrence) (b) create a new snapshot schedule (by selecting something other than 'None' in the recurrence field, given that no schedule exists yet) (c) edit an existing snapshot schedule (which is what this dialog is actually meant to do). I am not sure about (a), but it doesn't matter much for my point: New and Schedule have the exact same functionality. To be more accurate: New contains all of the needed functionality; Schedule is not really needed. The only thing that New is potentially missing is showing the values of the already-existing snapshot schedule, if one exists. I think that this may confuse to the user; I recommend to either unite both of these actions/dialogs to a single action/dialog, or separate completely some functionalists. So my recommendation is to do one of the following: (a) unite: Have a single action (Create / Schedule) which will display a dialog very similar to the New dialog, with the option to see the values of the already-existing snapshot schedule, if one exists. In this case, I would actually recommend to go with something more similar to option 2 in http://i.imgur.com/4j7hvRY.png, rather than option 3 (so the separation between *creating new* *one-time* snapshot and *editing an existing* *scheduled* snapshot is clearer). see http://i.imgur.com/ZgCp9Tz.png for an updated suggestion. - or - (b) separate: Have two completely separate actions: Create Now and Schedule. - The Create Now dialog will look like the 'General' side-section of the New dialog (i.e. without the Schedule side-section; it will allow only one-time immediate snapshot creation. - The Schedule dialog will look like the New dialog (with both 'General' and 'Schedule' side-sections) without the None recurrence, and will allow only creating a new recurring snapshot schedule (if one doesn't exist yet) or editing the existing schedule (in this case, the dialog would be pre-populated with the values of the existing schedule). I am more in favor of (b) - it seems simpler and more user-friendly in my view. Option (b) is something which we had started with, then at later stage it was discussed that scheduling as well should be in the flow of creation of snapshot so merged with New Snapshot option. After this as we need Edit option for snapshot schedule, so introduced Schedule option. But still, as you suggest I feel option (b) is no doubt a clearer and user friendly way. Alok, need a point of view from PMs on this. Thanks, Shubhendu. @Alok (and all): the main pain-point in the current design that I am trying to address is the fact that in the 'New' dialog, you have the option to create a one- time snapshot, and within the same dialog, with a very small (too small IMO) change, you have the option to edit (override) an already-existing schedule, without even realizing necessarily that you are editing something (since you are in a 'New' dialog) and without seeing the values of the object that you are editing. From a UX perspective, this may be confusing and misleading. if it is imperative to combine the one-time creation functionality with the scheduling functionality, you have option (a). here is another option (c) that will allow you to create a one-time snapshot and *create* a new schedule in the same dialog. it is also probably the closest option to the original design in the wiki, so I encourage you to consider it: (c) Have two options, New and Schedule, like today. - New will be *only* for creating new objects, not editing/overriding existing ones. It will look very
Re: [ovirt-devel] Gluster Volume Snapshots - Feature review
- Original Message - From: Shubhendu Tripathi shtri...@redhat.com Sent: Thursday, January 1, 2015 10:05:48 AM On 12/31/2014 11:42 PM, Einav Cohen wrote: Thanks, Shubhendu. Additional comments: ... Yes, attempt to create second snapshot schedule is actually an override option. Of course spot creation is allowed in addition to the scheduled. ... ... If the option Volumes - Snapshots - New selected, the dialog opens with pre-populated snapshot name prefix and Recurrence type selected as None by default. This effectively is one time snapshot creation. If this is first time and user wants to schedule the snapshot creation, he/she can change the recurrence type and provide details. Snapshot creation is scheduled in this case. Later, it user wants to edit the schedule, he/she needs to select option Volumes - Snapshots - Schedule (may be for this reason only I want to call it Edit Schedule). So effectively option Volumes - Snapshots - Schedule is meant for only re-scheduling the snapshot creation. If its not yet scheduled dialog opens with recurrence type selected as None. ... From your latest responses, I conclude the following. via the New dialog, you can: (1) create a one-time snapshot (2) create a new snapshot schedule (3) override (and practically, edit) an existing snapshot schedule via the Schedule dialog, you can: (a) create a one-time snapshot (by selecting the 'None' recurrence) (b) create a new snapshot schedule (by selecting something other than 'None' in the recurrence field, given that no schedule exists yet) (c) edit an existing snapshot schedule (which is what this dialog is actually meant to do). I am not sure about (a), but it doesn't matter much for my point: New and Schedule have the exact same functionality. To be more accurate: New contains all of the needed functionality; Schedule is not really needed. The only thing that New is potentially missing is showing the values of the already-existing snapshot schedule, if one exists. I think that this may confuse to the user; I recommend to either unite both of these actions/dialogs to a single action/dialog, or separate completely some functionalists. So my recommendation is to do one of the following: (a) unite: Have a single action (Create / Schedule) which will display a dialog very similar to the New dialog, with the option to see the values of the already-existing snapshot schedule, if one exists. In this case, I would actually recommend to go with something more similar to option 2 in http://i.imgur.com/4j7hvRY.png, rather than option 3 (so the separation between *creating new* *one-time* snapshot and *editing an existing* *scheduled* snapshot is clearer). see http://i.imgur.com/ZgCp9Tz.png for an updated suggestion. - or - (b) separate: Have two completely separate actions: Create Now and Schedule. - The Create Now dialog will look like the 'General' side-section of the New dialog (i.e. without the Schedule side-section; it will allow only one-time immediate snapshot creation. - The Schedule dialog will look like the New dialog (with both 'General' and 'Schedule' side-sections) without the None recurrence, and will allow only creating a new recurring snapshot schedule (if one doesn't exist yet) or editing the existing schedule (in this case, the dialog would be pre-populated with the values of the existing schedule). I am more in favor of (b) - it seems simpler and more user-friendly in my view. Option (b) is something which we had started with, then at later stage it was discussed that scheduling as well should be in the flow of creation of snapshot so merged with New Snapshot option. After this as we need Edit option for snapshot schedule, so introduced Schedule option. But still, as you suggest I feel option (b) is no doubt a clearer and user friendly way. Alok, need a point of view from PMs on this. Thanks, Shubhendu. @Alok (and all): the main pain-point in the current design that I am trying to address is the fact that in the 'New' dialog, you have the option to create a one- time snapshot, and within the same dialog, with a very small (too small IMO) change, you have the option to edit (override) an already-existing schedule, without even realizing necessarily that you are editing something (since you are in a 'New' dialog) and without seeing the values of the object that you are editing. From a UX perspective, this may be confusing and misleading. if it is imperative to combine the one-time creation functionality with the scheduling functionality, you have option (a). here is another option (c) that will allow you to create a one-time snapshot and *create* a new schedule in the same dialog. it is also probably the closest option to the original design in the wiki, so I encourage you to consider it: (c) Have two options, New and Schedule,
[ovirt-devel] SubnodeConfiguration, HierarchicalConfiguration and Checkstyle
Hi all, I started looking at building the engine using xmvn [1], see also [2] [3] if interested. The core of this project is to stop bundling modules we get from maven during build, and instead use ones packaged by the distribution (fedora or rhel for now). This will require, among other things, to adapt our existing code that uses such modules, to their versions as packaged by the distro. On first attempt I failed, due to currently using commons-configuration 1.6 where fedora 20 (where I do this) ships 1.9. If I change the pom to use 1.9, the build fails on the line: ListSubnodeConfiguration configurationsAt = config.configurationsAt(/*/ + ALTERNATE_KEY); in backend/manager/tools/src/main/java/org/ovirt/engine/core/config/EngineConfigLogic.java, saying they are of incompatible types. I tried a bit changing stuff there, and current status is that Checkstyle fails, with my current draft patch [4]. I'd appreciate some experienced Java developer to give this a look and advice on how to proceed. Thanks! I guess the other option is to Conflict (in the spec file) with the package shipped in fedora, and either bundle 1.6 as we do now or package it on the ovirt repo. I'd rather not go that route for now. [1] https://mizdebsk.fedorapeople.org/xmvn/site/ [2] http://fedoraproject.org/wiki/Packaging:Java [3] https://fedorahosted.org/released/javapackages/doc/ [4] http://gerrit.ovirt.org/36528 -- Didi ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Bump to 3.6 default cluster version
On 01/01/15 15:49, Eli Mesika wrote: - Original Message - From: Lior Vernia lver...@redhat.com To: devel@ovirt.org Cc: Eli Mesika emes...@redhat.com Sent: Thursday, January 1, 2015 3:42:18 PM Subject: Bump to 3.6 default cluster version Hello, Could we add the 3.6 version on master and change that to the default DC/cluster version? Some features are already merged, so they could be used and bugs could be found earlier by people working on master (mostly us developers I guess) once the version is bumped. I saw 6199b29506253eeae9712afea71a3641727de71b for 3.5 - however, I'm not sure I understand the logic behind what config values need to be added for old features to work, so I'd prefer not to be the one sending the patch. I already sent a draft on that http://gerrit.ovirt.org/#/c/36518/ I need reviews from network, storage , gluster virt Ahh, thank you! Just in time :) I'll take a look for network! Yours, Lior. ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Bump to 3.6 default cluster version
- Original Message - From: Lior Vernia lver...@redhat.com To: devel@ovirt.org Cc: Eli Mesika emes...@redhat.com Sent: Thursday, January 1, 2015 3:42:18 PM Subject: Bump to 3.6 default cluster version Hello, Could we add the 3.6 version on master and change that to the default DC/cluster version? Some features are already merged, so they could be used and bugs could be found earlier by people working on master (mostly us developers I guess) once the version is bumped. I saw 6199b29506253eeae9712afea71a3641727de71b for 3.5 - however, I'm not sure I understand the logic behind what config values need to be added for old features to work, so I'd prefer not to be the one sending the patch. I already sent a draft on that http://gerrit.ovirt.org/#/c/36518/ I need reviews from network, storage , gluster virt Yours, Lior. ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
[ovirt-devel] Bump to 3.6 default cluster version
Hello, Could we add the 3.6 version on master and change that to the default DC/cluster version? Some features are already merged, so they could be used and bugs could be found earlier by people working on master (mostly us developers I guess) once the version is bumped. I saw 6199b29506253eeae9712afea71a3641727de71b for 3.5 - however, I'm not sure I understand the logic behind what config values need to be added for old features to work, so I'd prefer not to be the one sending the patch. Yours, Lior. ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] UI Plugin to Upload ISO Files
On 12/29/2014 06:13 PM, Tony James wrote: On Mon, Dec 29, 2014 at 5:26 AM, Itamar Heim ih...@redhat.com wrote: On 12/29/2014 09:25 AM, Nir Soffer wrote: - Original Message - From: Tony James t...@anthonyjames.org To: devel@ovirt.org Sent: Monday, December 29, 2014 3:30:49 AM Subject: [ovirt-devel] UI Plugin to Upload ISO Files This message is in response to an earlier thread regarding a UI plugin to upload ISO files. Like the original poster, Lucas, I began work on a UI plugin to allow uploading ISO files through a UI plugin. After reading the previous thread I'm re-thinking the architecture. It was suggested that the recommended approach to upload files to a storage domain is through the VDSM API [1]. I'm pretty familiar with the oVirt REST API but have been unable to find documentation regarding accessing the VDSM API. Should the VDSM API be accessible by a UI plugin? If so, is there documentation available to do so? [1] http://lists.ovirt.org/pipermail/devel/2014-December/009497.html Basically you have to: 1. Use the vdsm xmlrpc/jsonrpc to create an image 2. Use the vdsm http api to upload the data to the image. This will create a task and return a task id. 3. Use the vdsm xmlrpc/jsonrpc api to check the task status, and clear the task when done The xmlrpc/jsonrpc api is documented here: http://gerrit.ovirt.org/gitweb?p=vdsm.git;a=blob;f=vdsm/rpc/vdsmapi-schema.json;h=1edcda86c8468b68c620eff4844b57ca30e44ea7;hb=HEAD You can check the code for upload here: http://gerrit.ovirt.org/gitweb?p=vdsm.git;a=blob;f=vdsm/rpc/BindingXMLRPC.py;h=759ed7845e63658a13c139684095bd56c03a29ac;hb=HEAD#l158 I assume the upload will be done via a servlet on the engine, not directly by the ui plugin accessing vdsm. worth discussing your plans here, to make sure architecture/security are correct. I was planning on using a python CGI script which would accept the upload via POST from the UI plugin. The file would be stored in /tmp on the engine host. After the file was successfully uploaded, the CGI script would send a POST to a python HTTP server (BaseHTTPServer, also running on engine host) with the filename and storage domain information. This python script would then take care of mounting the storage domain and copying the file to the appropriate location. This was my initial approach, I plan on checking out the VDSM API as well. my preference would be to stream via a servlet to the vdsm api, rather than store and forward to avoid potentially exhausting space on engine or having to deal with two phased task tracking. the tricky part which requires a review is validating authentication and authorization by the servlet - to make sure one has the permission to write to a certain disk (for data domains) / iso domain. this should be similar to the websocket novnc approach of validating user has access to relevant VM (but Alon may correct me if its different) notice there is one caveat for iso domains to having vdsm do the upload vs. the iso-uploader utility - it would require vdsm to have write permissions to the iso nfs path. but it allows uploading disks/vm's as well to data stores, which i think is worth having the same pattern for both. ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
