[prev in list] [next in list] [prev in thread] [next in thread] 

List:       rhq-devel
Subject:    deploying bundle to a single platform
From:       asantos () redhat ! com (Alan Santos)
Date:       2011-06-22 19:08:23
Message-ID: 94BF8CFE-63FD-4520-BCB3-1B6AFFC1E4BC () redhat ! com
[Download RAW message or body]

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


[prev in list] [next in list] [prev in thread] [next in thread]