Re: [ovirt-devel] [ovirt-users] [Feature review] Select network to be used for glusterfs
On Mon, Jan 12, 2015 at 02:59:50PM +0200, Lior Vernia wrote: On 12/01/15 14:44, Oved Ourfali wrote: Hi Sahina, Some comments: 1. As far as I understand, you might not have an IP available immediately after setupNetworks runs (getCapabilities should run, but it isn't run automatically, afair). 2. Perhaps you should pass not the IP but the name of the network? IPs might change. Actually, IP address can indeed change - which would be very bad for gluster functioning! I think moving networks or changing their IP addresses via Setup Networks should be blocked if they're used by gluster bricks. In the suggested feature, there is no real storage role. The storage role title means only default value for glusterfs IP. For example, once a brick was created, nothing protects the admin from accidently removing the storage network, or changing its IP address. Another proof that this is not a real role, is that it affects only GUI: I am guessing that REST API would not make use of it at all. (maybe I'm wrong; for sure, REST must be defined in the feature page) Maybe that's the behavior we want. But alternatively, Engine can enforce a stronger linkage between the brick to the network that it uses. When adding a brick, the dialog would list available networks instead of the specific IP. As long as the brick is being used, the admin would be blocked/warned against deleting the network. I'm missing a discussion regarding the upgrade path. If we would opt to requiring a single storage role network in a cluster, in an upgraded cluster the management network should take this role. 3. Adding to 2, perhaps using DNS names is a more valid approach? 4. You're using the terminology role, but it might be confusing, as we have roles with regards to permissions. Consider changing storage usage and not storage role in the feature page. Well, we've already been using this terminology for a while now concerning display/migration roles for networks... That's probably the terminology to use. Thanks, Oved - Original Message - From: Sahina Bose sab...@redhat.com To: devel@ovirt.org, users us...@ovirt.org Sent: Monday, January 12, 2015 2:00:16 PM Subject: [ovirt-users] [Feature review] Select network to be used for glusterfs Hi all, Please review the feature page for this proposed solution and provide your inputs - http://www.ovirt.org/Features/Select_Network_For_Gluster thanks sahina ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [ovirt-users] [Feature review] Select network to be used for glusterfs
On 12/01/15 14:44, Oved Ourfali wrote: Hi Sahina, Some comments: 1. As far as I understand, you might not have an IP available immediately after setupNetworks runs (getCapabilities should run, but it isn't run automatically, afair). 2. Perhaps you should pass not the IP but the name of the network? IPs might change. Actually, IP address can indeed change - which would be very bad for gluster functioning! I think moving networks or changing their IP addresses via Setup Networks should be blocked if they're used by gluster bricks. 3. Adding to 2, perhaps using DNS names is a more valid approach? 4. You're using the terminology role, but it might be confusing, as we have roles with regards to permissions. Consider changing storage usage and not storage role in the feature page. Well, we've already been using this terminology for a while now concerning display/migration roles for networks... That's probably the terminology to use. Thanks, Oved - Original Message - From: Sahina Bose sab...@redhat.com To: devel@ovirt.org, users us...@ovirt.org Sent: Monday, January 12, 2015 2:00:16 PM Subject: [ovirt-users] [Feature review] Select network to be used for glusterfs Hi all, Please review the feature page for this proposed solution and provide your inputs - http://www.ovirt.org/Features/Select_Network_For_Gluster thanks sahina ___ Users mailing list us...@ovirt.org http://lists.ovirt.org/mailman/listinfo/users ___ Users mailing list us...@ovirt.org http://lists.ovirt.org/mailman/listinfo/users ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [ovirt-users] [Feature review] Select network to be used for glusterfs
Hi Sahina, Some comments: 1. As far as I understand, you might not have an IP available immediately after setupNetworks runs (getCapabilities should run, but it isn't run automatically, afair). 2. Perhaps you should pass not the IP but the name of the network? IPs might change. 3. Adding to 2, perhaps using DNS names is a more valid approach? 4. You're using the terminology role, but it might be confusing, as we have roles with regards to permissions. Consider changing storage usage and not storage role in the feature page. Thanks, Oved - Original Message - From: Sahina Bose sab...@redhat.com To: devel@ovirt.org, users us...@ovirt.org Sent: Monday, January 12, 2015 2:00:16 PM Subject: [ovirt-users] [Feature review] Select network to be used for glusterfs Hi all, Please review the feature page for this proposed solution and provide your inputs - http://www.ovirt.org/Features/Select_Network_For_Gluster thanks sahina ___ Users mailing list us...@ovirt.org http://lists.ovirt.org/mailman/listinfo/users ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Gluster Volume Snapshots - Feature review
- Original Message - From: Shubhendu Tripathi shtri...@redhat.com To: Einav Cohen eco...@redhat.com, Alok Srivastava asriv...@redhat.com Cc: de...@linode01.ovirt.org, rhsc-dev rhsc-...@redhat.com Sent: Thursday, January 1, 2015 11:30:41 PM Subject: 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
