deploying bundle to a single platform

Alan Santos asantos at redhat.com
Wed Jun 22 19:08:23 UTC 2011


fwiw, I disagree and it's a common request.  

more below


> On 6/21/2011 5:18 PM, John Mazzitelli wrote:
>> 
>> First, the data model strictly requires bundle deployments to be
>> associated with groups. Without some major surgery, we can't change the
>> data model to support groups AND single resources (and all the
>> server-side business logic that would go along with that).

noted.

>> can we just have some convenient way to select a
>> single resource but then we create a group under the covers
[snip]
>> For example, in the deploy wizard's "create destination" step, we have a
>> drop down to select a group. We would have to have some kind of other UI
>> component to select a single resource.

Why wouldn't you have a single drop down that lists both groups and compatible resources?


>> Suppose we have that. I select a
>> resource. What would be the group's name?
[snip]
>>  Either way, they need to go into some
>> UI component to select a resource. But without the group wizard, they
>> have no way of assigning their group their own custom name.


[target resource].[artifact name].[version] or custom name provided with optional 'fill in more detail' widgets? But if you read below, there's no reason you couldn't just give it a meaningless, unique id.


>> Whatever group is created will
>> show up in the list of groups in other places in the UI,
[snip]
>> If we assign our own default name under the covers, since the user
>> doesn't know that we are creating a group, it will seem odd that he sees
>> this strangely named group that he didn't knowingly create appear in his
>> group list (say, if he goes to Inventory>AllGroups).
[snip]
>> 
>> 2) without going through some kind of group-creation workflow (that is,
>> we create the group under the covers once the user selected the
>> individual resource), we will be forced to give a default name to this
>> group we create under the covers. The user will then possibly be
>> confused later on when he sees this oddly named group in his list of
>> groups - something in which he didn't create, he didn't name, and quite
>> possible won't know why it is created.


Only if you can't filter automatically created groups. If you're going to build something under the covers, it seems like it ought to stay under the covers. Regardless, I think we both agree that a user shouldn't see auto-created groups with everything else. 

And by the way - besides the user knowing why it is there, this is the case now - the user created groups add noise to the report, serve as a reminder of additional work done to accommodate an internal implementation choice and adding maintenance or leaving garbage behind if the app is ever undeployed.


>> 
>> 1) the UI workflow will not be significantly simpler for the user. The
>> user will need to select the individual resource from SOMEWHERE. That
>> somewhere is either in a UI component directly on the deploy wizard or
>> in the Group Create Wizard.
[snip]
>> If we DO ask the user to give us a name, why not popup the group create
>> wizard itself? Not much different and at least the group create wizard
>> is a common component the user should be used to and provides more
>> capability.


Unless I misunderstand, it seems defaults can halve the number of high level steps (1. Create a group,  2. deploy the bundle vs 1. deploy the bundle)

Your suggestion (popup the group wizard) doesn't address the dissonance for a user who asks 'why am doing unrelated, unhelpful work when I just want to deploy to a single server?'.  Popping up a group wizard may make the process slightly less painful, but not by much and then the group just sits around as maintenance.


-alan





More information about the rhq-devel mailing list