In 4.9 we'll be introducing support for bundle groups and fine-grained bundle permissions. This will allow for better organization of your bundles and much tighter control over how bundles are manipulated. We're working on GUI support now and there is one thing on which I'd like your opinion.
Currently, in the bundle create wizard you just upload your bundle distribution file, (or specify a URL, or provide the recipe...) and then the bundle version gets created. If it is the first version the associated bundle is also created as an umbrella for all the related versions.
Going forward, new bundles can be (or in certain cases, must be) assigned to at least one bundle group. That means if the upload is for the initial bundle version there may need to be an additional step for group assignment. But for subsequent versions it's not relevant, because the bundle itself is not being created; it already exists and has already been assigned to its bundle groups.
The question is this: As a bundle creator, is it OK to distinguish between "New Bundle" and "Upload New Version for Existing Bundle"? Basically, can you answer that question up front when uploading a bundle distribution file. Is this the initial bundle version or is it a new version for a bundle already in the system?
If that distinction can be made, RHQ will likely ask you to make that distinction. If not then RHQ won't ask, but it will make things more clunky internally, and possibly in the wizard as well.
The question is this: As a bundle creator, is it OK to distinguish between "New Bundle" and "Upload New Version for Existing Bundle"? Basically, can you answer that question up front when uploading a bundle distribution file. Is this the initial bundle version or is it a new version for a bundle already in the system?
If that distinction can be made, RHQ will likely ask you to make that distinction. If not then RHQ won't ask, but it will make things more clunky internally, and possibly in the wizard as well.
I'm going to poison the well and put my opinion out there. Others are welcome to oppose my thinking, but here goes.
It is very convenient to allow the user to simply upload a bundle distro file - any bundle distro file - and let the system simply determine the right thing to do. There is no real reason (from the user perspective) why the user HAS to let the system know "this is the very first version of a new bundle" versus "this is a subsequent version of a new bundle". If you force them to do this, now they will not only have to know that, but, if it IS a subsequent version to an existing bundle, they will have the new burden of searching through the set of visible bundles, selecting it, and then pressing the "new version" button. Takes additional time and additional clicks and therefore is not as user friendly.
Secondly, it still doesn't solve the problem. The problem that you are trying to solve - avoid having the server receive the full distro file, crack it open, parse the recipe, and determine if its a new bundle or existing bundle - is still unavoidable. Because, now you have to confirm if the user really selected the correct bundle in the first place. If the user selected Bundle A, clicked "New Version" - the server still has to receive the full distro, crack it open, and parse the recipe to confirm the user was right, that this really was for Bundle A. Because it is not, if its for Bundle B, the server must error out - it cannot continue. The user will then be told a very annoying message, "you selected bundle A but you gave the server bundle B - please select the correct bundle and try again".
So, you still must error out and ask the user to send the distro a second time, because of either
a) they don't have the proper security credentials to submit a bundle that is unassigned
or
b) they selected the wrong thing in the UI
Either way, the problem stands. But in the case of b) you made them go through extra annoying steps that they didn't have to do before and shouldn't have to do now. In a) you made them go through extra steps because they attempted to do something that they weren't allowed to do. I submit it is better to make them do extra steps because they violated security constraints - it is more user friendly to not make them select a bundle (and potentially get it wrong, when the server can figure it out by itself) and upload only to be told after upload a large file that they picked the wrong thing in the UI.
Since John poisoned the well - I'll hop in too ;).
+1 to John, although I do think that "New" as an action button doesn't necessarily tell you we'll automatically do the right thing for you in the version upgrade case and therefore we could improve something there, either the button name or the descriptive text in the first wizard panel probably.
It seems today today the system just "does the right thing" regarding whether it is a new bundle or an upgrade to an existing bundle. I uploaded a new version today and it never asked me whether it was a new bundle or not, and just incremented the version of the bundle I was upgrading. I wouldn't expect this behavior to change just because bundles are now in bundle groups.
- Catherine
John Mazzitelli wrote:
The question is this: As a bundle creator, is it OK to distinguish between "New Bundle" and "Upload New Version for Existing Bundle"? Basically, can you answer that question up front when uploading a bundle distribution file. Is this the initial bundle version or is it a new version for a bundle already in the system?
If that distinction can be made, RHQ will likely ask you to make that distinction. If not then RHQ won't ask, but it will make things more clunky internally, and possibly in the wizard as well.
I'm going to poison the well and put my opinion out there. Others are welcome to oppose my thinking, but here goes.
It is very convenient to allow the user to simply upload a bundle distro file - any bundle distro file - and let the system simply determine the right thing to do. There is no real reason (from the user perspective) why the user HAS to let the system know "this is the very first version of a new bundle" versus "this is a subsequent version of a new bundle". If you force them to do this, now they will not only have to know that, but, if it IS a subsequent version to an existing bundle, they will have the new burden of searching through the set of visible bundles, selecting it, and then pressing the "new version" button. Takes additional time and additional clicks and therefore is not as user friendly.
Secondly, it still doesn't solve the problem. The problem that you are trying to solve - avoid having the server receive the full distro file, crack it open, parse the recipe, and determine if its a new bundle or existing bundle - is still unavoidable. Because, now you have to confirm if the user really selected the correct bundle in the first place. If the user selected Bundle A, clicked "New Version" - the server still has to receive the full distro, crack it open, and parse the recipe to confirm the user was right, that this really was for Bundle A. Because it is not, if its for Bundle B, the server must error out - it cannot continue. The user will then be told a very annoying message, "you selected bundle A but you gave the server bundle B - please select the correct bundle and try again".
So, you still must error out and ask the user to send the distro a second time, because of either
a) they don't have the proper security credentials to submit a bundle that is unassigned
or
b) they selected the wrong thing in the UI
Either way, the problem stands. But in the case of b) you made them go through extra annoying steps that they didn't have to do before and shouldn't have to do now. In a) you made them go through extra steps because they attempted to do something that they weren't allowed to do. I submit it is better to make them do extra steps because they violated security constraints - it is more user friendly to not make them select a bundle (and potentially get it wrong, when the server can figure it out by itself) and upload only to be told after upload a large file that they picked the wrong thing in the UI. _______________________________________________ rhq-users mailing list rhq-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/rhq-users
On 8/15/2013 9:46 AM, John Mazzitelli wrote:
The question is this: As a bundle creator, is it OK to distinguish between "New Bundle" and "Upload New Version for Existing Bundle"? Basically, can you answer that question up front when uploading a bundle distribution file. Is this the initial bundle version or is it a new version for a bundle already in the system?
If that distinction can be made, RHQ will likely ask you to make that distinction. If not then RHQ won't ask, but it will make things more clunky internally, and possibly in the wizard as well.
I'm going to poison the well and put my opinion out there. Others are welcome to oppose my thinking, but here goes.
It is very convenient to allow the user to simply upload a bundle distro file - any bundle distro file - and let the system simply determine the right thing to do. There is no real reason (from the user perspective) why the user HAS to let the system know "this is the very first version of a new bundle" versus "this is a subsequent version of a new bundle". If you force them to do this, now they will not only have to know that, but, if it IS a subsequent version to an existing bundle, they will have the new burden of searching through the set of visible bundles, selecting it, and then pressing the "new version" button. Takes additional time and additional clicks and therefore is not as user friendly.
Well no, they do not need to select the bundle for which this is a new version. They only need to know if this is a new bundle (version 1) upload or an existing bundle (version 2..N). It's just a distinction between those two options, you don't have to be in the context of the existing bundle to upload the new version.
Secondly, it still doesn't solve the problem. The problem that you are trying to solve - avoid having the server receive the full distro file, crack it open, parse the recipe, and determine if its a new bundle or existing bundle - is still unavoidable. Because, now you have to confirm if the user really selected the correct bundle in the first place. If the user selected Bundle A, clicked "New Version" - the server still has to receive the full distro, crack it open, and parse the recipe to confirm the user was right, that this really was for Bundle A. Because it is not, if its for Bundle B, the server must error out - it cannot continue. The user will then be told a very annoying message, "you selected bundle A but you gave the server bundle B - please select the correct bundle and try again".
No, this is not true, see above. The issue you mention is the crux of the problem, though. We don't know if the actual distribution file is for an existing bundle until the file is sucked in by the server, cracked open, the recipe is parsed and the bundle name is found. Then we can figure out if the bundle already exists or not.
The problem we have is that unless the user has significant global permissions, we will fail being able to create a new bundle without bundle group assignment. So we upload this potentially large file to the server, crack it open, and fail because it's for a new bundle and we didn't ask the user for initial bundle groups that it should be in. Even if we cover up this failure in the Wizard, we'd then have to go back and ask them for the initial groups, and then try again, uploading again the potentially large file.
This failure, and a lot of code complexity can be avoided if the user can answer the question up front: New bundle or New version for existing bundle.
So, you still must error out and ask the user to send the distro a second time, because of either
That error out and second upload causes complexity and potential slowness for large files.
a) they don't have the proper security credentials to submit a bundle that is unassigned
or
b) they selected the wrong thing in the UI
Again, they don't have to select an existing bundle, just select the one option. Of course if they hit the wrong option they will get an error. Something like "Bundle already exists, can't create new bundle" or "Bundle does not exist, can not add new version".
Either way, the problem stands. But in the case of b) you made them go through extra annoying steps that they didn't have to do before and shouldn't have to do now. In a) you made them go through extra steps because they attempted to do something that they weren't allowed to do. I submit it is better to make them do extra steps because they violated security constraints - it is more user friendly to not make them select a bundle (and potentially get it wrong, when the server can figure it out by itself) and upload only to be told after upload a large file that they picked the wrong thing in the UI. _______________________________________________ rhq-users mailing list rhq-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/rhq-users
After banging on this some more with Mazz I think we have a solution that will avoid having to make the decision up front and also avoid multiple uploads. So, this is likely closed, although any comments are still welcome.
On 8/15/2013 9:58 AM, Jay Shaughnessy wrote:
On 8/15/2013 9:46 AM, John Mazzitelli wrote:
The question is this: As a bundle creator, is it OK to distinguish between "New Bundle" and "Upload New Version for Existing Bundle"? Basically, can you answer that question up front when uploading a bundle distribution file. Is this the initial bundle version or is it a new version for a bundle already in the system?
If that distinction can be made, RHQ will likely ask you to make that distinction. If not then RHQ won't ask, but it will make things more clunky internally, and possibly in the wizard as well.
I'm going to poison the well and put my opinion out there. Others are welcome to oppose my thinking, but here goes.
It is very convenient to allow the user to simply upload a bundle distro file - any bundle distro file - and let the system simply determine the right thing to do. There is no real reason (from the user perspective) why the user HAS to let the system know "this is the very first version of a new bundle" versus "this is a subsequent version of a new bundle". If you force them to do this, now they will not only have to know that, but, if it IS a subsequent version to an existing bundle, they will have the new burden of searching through the set of visible bundles, selecting it, and then pressing the "new version" button. Takes additional time and additional clicks and therefore is not as user friendly.
Well no, they do not need to select the bundle for which this is a new version. They only need to know if this is a new bundle (version 1) upload or an existing bundle (version 2..N). It's just a distinction between those two options, you don't have to be in the context of the existing bundle to upload the new version.
Secondly, it still doesn't solve the problem. The problem that you are trying to solve - avoid having the server receive the full distro file, crack it open, parse the recipe, and determine if its a new bundle or existing bundle - is still unavoidable. Because, now you have to confirm if the user really selected the correct bundle in the first place. If the user selected Bundle A, clicked "New Version" - the server still has to receive the full distro, crack it open, and parse the recipe to confirm the user was right, that this really was for Bundle A. Because it is not, if its for Bundle B, the server must error out - it cannot continue. The user will then be told a very annoying message, "you selected bundle A but you gave the server bundle B - please select the correct bundle and try again".
No, this is not true, see above. The issue you mention is the crux of the problem, though. We don't know if the actual distribution file is for an existing bundle until the file is sucked in by the server, cracked open, the recipe is parsed and the bundle name is found. Then we can figure out if the bundle already exists or not.
The problem we have is that unless the user has significant global permissions, we will fail being able to create a new bundle without bundle group assignment. So we upload this potentially large file to the server, crack it open, and fail because it's for a new bundle and we didn't ask the user for initial bundle groups that it should be in. Even if we cover up this failure in the Wizard, we'd then have to go back and ask them for the initial groups, and then try again, uploading again the potentially large file.
This failure, and a lot of code complexity can be avoided if the user can answer the question up front: New bundle or New version for existing bundle.
So, you still must error out and ask the user to send the distro a second time, because of either
That error out and second upload causes complexity and potential slowness for large files.
a) they don't have the proper security credentials to submit a bundle that is unassigned
or
b) they selected the wrong thing in the UI
Again, they don't have to select an existing bundle, just select the one option. Of course if they hit the wrong option they will get an error. Something like "Bundle already exists, can't create new bundle" or "Bundle does not exist, can not add new version".
Either way, the problem stands. But in the case of b) you made them go through extra annoying steps that they didn't have to do before and shouldn't have to do now. In a) you made them go through extra steps because they attempted to do something that they weren't allowed to do. I submit it is better to make them do extra steps because they violated security constraints - it is more user friendly to not make them select a bundle (and potentially get it wrong, when the server can figure it out by itself) and upload only to be told after upload a large file that they picked the wrong thing in the UI. _______________________________________________ rhq-users mailing list rhq-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/rhq-users
rhq-users mailing list rhq-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/rhq-users
rhq-users@lists.stg.fedorahosted.org
-
Catherine Robson -
Jay Shaughnessy -
John Mazzitelli