[katello-devel] dyanmic system groups?

Bryan Kearney bkearney at redhat.com
Thu Jun 6 16:26:33 UTC 2013 

On 06/06/2013 10:09 AM, Tom McKay wrote:
>
>
> ----- Original Message -----
>> From: "Bryan Kearney" <bkearney at redhat.com>
>> To: katello-devel at redhat.com
>> Sent: Thursday, June 6, 2013 9:07:18 AM
>> Subject: Re: [katello-devel] dyanmic system groups?
>>
>> On 06/05/2013 03:49 PM, Tom McKay wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Kyle Baker" <kybaker at redhat.com>
>>>> To: "Tom McKay" <thomasmckay at redhat.com>
>>>> Cc: "Robb Hamilton" <rhamilto at redhat.com>, "Dan Lah" <dlah at redhat.com>,
>>>> "Amanda Carter" <acarter at redhat.com>, "Matt
>>>> Reid" <mreid at redhat.com>, katello-devel at redhat.com
>>>> Sent: Wednesday, June 5, 2013 3:40:25 PM
>>>> Subject: Re: [katello-devel] dyanmic system groups?
>>>>
>>>>
>>>>
>>>> ----- Original Message -----
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Tom McKay" <thomasmckay at redhat.com>
>>>>>> To: katello-devel at redhat.com
>>>>>> Sent: Monday, June 3, 2013 3:32:21 PM
>>>>>> Subject: dyanmic system groups?
>>>>>>
>>>>>>
>>>>>> I have a conundrum: Red Hat subscriptions need some grouping and yet
>>>>>> there
>>>>>> is
>>>>>> value in having them individually accessible as well.
>>>>>>
>>>>>> For example, I could get a manifest with RHEL in it of quantity 10, or I
>>>>>> could get 10 RHEL of quantity 1. Additionally when I consume some
>>>>>> subscriptions, that consumption triggers the creation of new bonus pools
>>>>>> for
>>>>>> VMs.
>>>>>>
>>>>>> While I could make a saved search of "RHEL" on the subscriptions list,
>>>>>> what
>>>>>> I
>>>>>> really need is a single entry in a "Subscription Groups" page that, when
>>>>>> selected, performs the dynamic search for me. System Groups, as you
>>>>>> know,
>>>>>> is
>>>>>> not dynamic. Having a subscription group would let me have more
>>>>>> informative
>>>>>> information on the right pane while maintaining the individual
>>>>>> subscriptions.
>>>>>>
>>>>>> My question, then, is was there discussion in the past of having dynamic
>>>>>> system groups and how they should behave? Even if the dynamic aspect
>>>>>> doesn't
>>>>>> make it to systems, I'd like to take any ideas into account if I choose
>>>>>> to
>>>>>> go with this for subscriptions.
>>>>>>
>>>>>> Thanks!
>>>>>
>>>>> Attached are two screenies:
>>>>>
>>>>> subs-individual.png - This is the current subscriptions listing. As you
>>>>> can
>>>>> see, for the fictional product "Awesome OS Instance Based (Standard
>>>>> Support)" there are three entries in the list: A 20 quantity, a 10
>>>>> quantity,
>>>>> and a single bonus virtual guest subscription.
>>>>>
>>>>> subs-grouped.png - This is a quickly-coded where subscriptions are
>>>>> grouped
>>>>> by
>>>>> name. In this case you'll see the single entry in the list with "(3)"
>>>>> after
>>>>> it. Selecting that entry displays the details of each of the three
>>>>> subscriptions.
>>>>>
>>>>> There certainly will be some display challenges for the column-based
>>>>> display
>>>>> of subs if there are more than is reasonable to quickly stuff into
>>>>> columns.
>>>>> For example, it is possible to get a manifest not with a subscription of
>>>>> quantity 20, but instead to get 20 subscriptions of quantity one. Now
>>>>> imagine 2000 subs of quantity one.
>>>>>
>>>>> I do like the columns, though, and the ease with which I am able to
>>>>> quickly
>>>>> identify one I had in mind. That said, when we go to the nutupane where
>>>>> the
>>>>> "left" list is now full width with individual columns I'm not sure I
>>>>> wouldn't rather be searching over on that list. There's no reason that
>>>>> both
>>>>> views can't coexist, though.
>>>>>
>>>>> I should also note that the grouped display is currently showing grouping
>>>>> by
>>>>> name. I could group by "Stacking ID" or "Provided Product" or some other
>>>>> combination of attributes. This might benefit user stories such as, "Find
>>>>> me
>>>>> all of the subscriptions that provide RHEL that are stackable covering
>>>>> sockets." Again, this just seems to point out that we need the advanced
>>>>> search form I'm pondered on in the past for the original individual
>>>>> subscription listing.
>>>>>
>>>>> Thoughts welcome! (Sent directly to a few folks that need to give this a
>>>>> closer look.)
>>>>
>>>> I think it would be best to avoid fragmenting the subscriptions into
>>>> grouped
>>>> and non-grouped sections. By creating a new section just for a grouping
>>>> mechanism it will give the illusion that we are displaying a new type of
>>>> content. The result would be unnecessary potential user confusion. It will
>>>> also make the UI workflow more cumbersome by adding additional options in
>>>> the nav without actually adding functionality. I would rather have a
>>>> parent/child relationship between the subscriptions within the list
>>>> itself.
>>>> I think it could work within the old-pane or nu-pane.
>>>>
>>>
>>>
>>> I completely agree. The grouped view I coded up does not add a whole lot of
>>> value, imho.
>>>
>>> There is currently no support planned for having the nu-pane to have
>>> expandable rows. I think this would probably be the correct solution,
>>> though.
>>>
>>>    | Name                                        | Consumed | ...
>>> v Awesome OS Instance Based (Standard Support) | 6 of 34  | ...
>>> ^-- v = expansion arrow
>>>
>>>    | Name                                        | Consumed | ...
>>>> Awesome OS Instance Based (Standard Support) | 6 of 34  | ...
>>> o Awesome OS Instance Based (Standard Support) | 4 of 10  |
>>> o Awesome OS Instance Based (Standard Support) | 2 of 4   |
>>> o Awesome OS Instance Based (Standard Support) | 0 of 20  |
>>>
>>> This would give best of both: Collapse by criteria (name, contract number,
>>> etc.) with expand to details.
>>>
>>> This will take significant development work.
>>
>> I like this type of apprach. If we can show a grouping by name, and then
>> in that show the unique contract items that would be good.
>>
>> I also like the idea of "hiding" bonus pools some how.
>>
>> Having them in a column to the right I do not think will scale.
>>
>> - bk
>>
>>
>> _______________________________________________
>> katello-devel mailing list
>> katello-devel at redhat.com
>> https://www.redhat.com/mailman/listinfo/katello-devel
>>
>
> Attached is a screenshot of the existing activation key page that is behaving as I am imagining it would look in nutupane.
>
> Again, note that this interaction is not currently scheduled/designed for inclusion in nutupane work.
>
Ack... this would be really nice in nutupane.

-- bk

More information about the katello-devel mailing list