Customizing "views" of resources

Development
1

For a while I've wanted to have different "views" of resources, specifically content hosts, depending on which task I'm performing at that moment.

For example, if my job today is to set up subscriptions on a group of content hosts, then I'd like the UI columns to be centered around that (red/yellow/green subscription status, last subscription-manager check-in time, registered date, registered-by user name, etc.). Tomorrow when I'm evaluating a group of content hosts for applicable errata the columns should be different (red/yellow/green errata types, last yum update date, etc.).

In addition to the UI, the hammer 'list' command output should reflect the task at hand.

For performance (or other) reasons the API could limit its output to that necessary. (eg. Why query candlepin for subscription status if checking errata?)

With the upcoming work on folding katello's content host into foreman's host model[1] the API will already be needing an adjustment to params to account for the various "aspects".

With both hammer and (some of) the UI being 100% driven off of API, starting there and expanding to the UI and hammer may be good. Design work towards how to define "views" in both UI and hammer could hopefully be derived from the API syntax.

Do I define a "view" in rabl and have the controller switch based on params?

/api/hosts?view=subscription
/api/hosts?view=provision
/api/hosts?view=errata

Do we need fully customizable attributes?

/api/hosts?include=content.entitlement_status

Any ideas on this?

[1] HostUnification - Katello - Foreman

··· -- @thomasmckay

–
“The leader must aim high, see big, judge widely, thus setting himself apart form the ordinary people who debate in narrow confines.” ~ Charles De Gaulle

“Leadership is about making others better as a result of your presence and making sure that impact lasts in your absence.” ~ Harvard Business School

2

> For a while I've wanted to have different "views" of resources,
> specifically content hosts, depending on which task I'm performing at that
> moment.
>
> For example, if my job today is to set up subscriptions on a group of
> content hosts, then I'd like the UI columns to be centered around that
> (red/yellow/green subscription status, last subscription-manager check-in
> time, registered date, registered-by user name, etc.). Tomorrow when I'm
> evaluating a group of content hosts for applicable errata the columns
> should be different (red/yellow/green errata types, last yum update date,
> etc.).
>
> In addition to the UI, the hammer 'list' command output should reflect the
> task at hand.
>
> For performance (or other) reasons the API could limit its output to that
> necessary. (eg. Why query candlepin for subscription status if checking
> errata?)
>
> With the upcoming work on folding katello's content host into foreman's
> host model[1] the API will already be needing an adjustment to params to
> account for the various "aspects".
>
> With both hammer and (some of) the UI being 100% driven off of API,
> starting there and expanding to the UI and hammer may be good. Design work
> towards how to define "views" in both UI and hammer could hopefully be
> derived from the API syntax.
>
> Do I define a "view" in rabl and have the controller switch based on
> params?
>
> /api/hosts?view=subscription
> /api/hosts?view=provision
> /api/hosts?view=errata
>
> Do we need fully customizable attributes?
>
> /api/hosts?include=content.entitlement_status
>
> Any ideas on this?
>
>
AFAIR, joseph suggested something like that a long time ago.

Ohad

··· On Wed, Aug 26, 2015 at 5:45 PM, Tom McKay wrote:

[1] HostUnification - Katello - Foreman

–
@thomasmckay

–
“The leader must aim high, see big, judge widely, thus setting himself
apart form the ordinary people who debate in narrow confines.” ~ Charles De
Gaulle

“Leadership is about making others better as a result of your presence and
making sure that impact lasts in your absence.” ~ Harvard Business School

–
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

3

>
>
>
>> For a while I've wanted to have different "views" of resources,
>> specifically content hosts, depending on which task I'm performing at that
>> moment.
>>
>> For example, if my job today is to set up subscriptions on a group of
>> content hosts, then I'd like the UI columns to be centered around that
>> (red/yellow/green subscription status, last subscription-manager check-in
>> time, registered date, registered-by user name, etc.). Tomorrow when I'm
>> evaluating a group of content hosts for applicable errata the columns
>> should be different (red/yellow/green errata types, last yum update date,
>> etc.).
>>
>> In addition to the UI, the hammer 'list' command output should reflect
>> the task at hand.
>>
>> For performance (or other) reasons the API could limit its output to that
>> necessary. (eg. Why query candlepin for subscription status if checking
>> errata?)
>>
>> With the upcoming work on folding katello's content host into foreman's
>> host model[1] the API will already be needing an adjustment to params to
>> account for the various "aspects".
>>
>> With both hammer and (some of) the UI being 100% driven off of API,
>> starting there and expanding to the UI and hammer may be good. Design work
>> towards how to define "views" in both UI and hammer could hopefully be
>> derived from the API syntax.
>>
>> Do I define a "view" in rabl and have the controller switch based on
>> params?
>>
>> /api/hosts?view=subscription
>> /api/hosts?view=provision
>> /api/hosts?view=errata
>>
>> Do we need fully customizable attributes?
>>
>> /api/hosts?include=content.entitlement_status
>>
>> Any ideas on this?
>>
>>
> AFAIR, joseph suggested something like that a long time ago.
>

yes, there is an old redmine ticket for customized API responses based on
parameters
http://projects.theforeman.org/issues/3019

My suggestion would be to follow the jsonapi.org spec (
http://jsonapi.org/format/) if we decide to do this

GET /articles/1?include=comments.author

··· On Wed, Aug 26, 2015 at 11:17 PM, Ohad Levy wrote: > On Wed, Aug 26, 2015 at 5:45 PM, Tom McKay wrote:

Ohad

[1] HostUnification - Katello - Foreman

–
@thomasmckay

–
“The leader must aim high, see big, judge widely, thus setting himself
apart form the ordinary people who debate in narrow confines.” ~ Charles De
Gaulle

“Leadership is about making others better as a result of your presence
and making sure that impact lasts in your absence.” ~ Harvard Business
School

–
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

4

>
>
>
>
>
> For a while I've wanted to have different "views" of
> resources, specifically content hosts, depending on which task
> I'm performing at that moment.
>
> For example, if my job today is to set up subscriptions on a
> group of content hosts, then I'd like the UI columns to be
> centered around that (red/yellow/green subscription status,
> last subscription-manager check-in time, registered date,
> registered-by user name, etc.). Tomorrow when I'm evaluating a
> group of content hosts for applicable errata the columns
> should be different (red/yellow/green errata types, last yum
> update date, etc.).
>
> In addition to the UI, the hammer 'list' command output should
> reflect the task at hand.
>
> For performance (or other) reasons the API could limit its
> output to that necessary. (eg. Why query candlepin for
> subscription status if checking errata?)
>
> With the upcoming work on folding katello's content host into
> foreman's host model[1] the API will already be needing an
> adjustment to params to account for the various "aspects".
>
> With both hammer and (some of) the UI being 100% driven off of
> API, starting there and expanding to the UI and hammer may be
> good. Design work towards how to define "views" in both UI and
> hammer could hopefully be derived from the API syntax.
>
> Do I define a "view" in rabl and have the controller switch
> based on params?
>
> /api/hosts?view=subscription
> /api/hosts?view=provision
> /api/hosts?view=errata
>
> Do we need fully customizable attributes?
>
> /api/hosts?include=content.entitlement_status
>

I don't think we need fully customized attributes. Specifying which
'aspects' to include should be sufficient IMHO.

>
> Any ideas on this?
>
>
> AFAIR, joseph suggested something like that a long time ago.
>
>
> yes, there is an old redmine ticket for customized API responses based
> on parameters
> Feature #3019: API customized responses - specify fields and/or relationships(fields) to be included in response - Foreman
>
> My suggestion would be to follow the jsonapi.org <http://jsonapi.org>
> spec (http://jsonapi.org/format/) if we decide to do this
>
> GET/articles/1?include=comments.author
>
Given that the current api is not jsonapi compatible (and we need to add
support for this to the existing hosts api), i think it would make sense
to use something similar but more rails-esque, such as:

/hosts?include[]=puppet&include[]=content

vs the jsonapi way of:

/hosts/?include=puppet,content

I also don't know that we need full relationship support (i.e.
comments.author).

-Justin

··· On 08/26/2015 04:26 PM, Joseph Magen wrote: > On Wed, Aug 26, 2015 at 11:17 PM, Ohad Levy > wrote: > On Wed, Aug 26, 2015 at 5:45 PM, Tom McKay > wrote: 
Ohad

    [1]
    http://projects.theforeman.org/projects/katello/wiki/HostUnification

    --
    @thomasmckay

    --
    "The leader must aim high, see big, judge widely, thus setting
    himself apart form the ordinary people who debate in narrow
    confines." ~ Charles De Gaulle

    "Leadership is about making others better as a result of your
    presence and making sure that impact lasts in your absence." ~
    Harvard Business School

    --
    You received this message because you are subscribed to the
    Google Groups "foreman-dev" group.
    To unsubscribe from this group and stop receiving emails from
    it, send an email to foreman-dev+unsubscribe@googlegroups.com
    <mailto:foreman-dev%2Bunsubscribe@googlegroups.com>.
    For more options, visit https://groups.google.com/d/optout.

–
You received this message because you are subscribed to the Google
Groups “foreman-dev” group.
To unsubscribe from this group and stop receiving emails from it, send
an email to foreman-dev+unsubscribe@googlegroups.com
mailto:foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

5

My thinking would be that new syntax should follow a defined standard. In this way, when v3 comes out it could honor that standard and some existing work could remain unchanged. If we could agree to a standard and then follow it where it makes sense in v2, that would be a good start.

Is jsonapi.org agreeable in a whole, or are there alternatives? Do we take an alternative and modify it for ourselves?

··· ----- Original Message ----- > On 08/26/2015 04:26 PM, Joseph Magen wrote: > > > > On Wed, Aug 26, 2015 at 11:17 PM, Ohad Levy > > wrote: > > > > > > > > On Wed, Aug 26, 2015 at 5:45 PM, Tom McKay > > wrote: > > > > For a while I've wanted to have different "views" of > > resources, specifically content hosts, depending on which task > > I'm performing at that moment. > > > > For example, if my job today is to set up subscriptions on a > > group of content hosts, then I'd like the UI columns to be > > centered around that (red/yellow/green subscription status, > > last subscription-manager check-in time, registered date, > > registered-by user name, etc.). Tomorrow when I'm evaluating a > > group of content hosts for applicable errata the columns > > should be different (red/yellow/green errata types, last yum > > update date, etc.). > > > > In addition to the UI, the hammer 'list' command output should > > reflect the task at hand. > > > > For performance (or other) reasons the API could limit its > > output to that necessary. (eg. Why query candlepin for > > subscription status if checking errata?) > > > > With the upcoming work on folding katello's content host into > > foreman's host model[1] the API will already be needing an > > adjustment to params to account for the various "aspects". > > > > With both hammer and (some of) the UI being 100% driven off of > > API, starting there and expanding to the UI and hammer may be > > good. Design work towards how to define "views" in both UI and > > hammer could hopefully be derived from the API syntax. > > > > Do I define a "view" in rabl and have the controller switch > > based on params? > > > > /api/hosts?view=subscription > > /api/hosts?view=provision > > /api/hosts?view=errata > > > > Do we need fully customizable attributes? > > > > /api/hosts?include=content.entitlement_status > > > > I don't think we need fully customized attributes. Specifying which > 'aspects' to include should be sufficient IMHO. > > > > > Any ideas on this? > > > > > > AFAIR, joseph suggested something like that a long time ago. > > > > > > yes, there is an old redmine ticket for customized API responses based > > on parameters > > http://projects.theforeman.org/issues/3019 > > > > My suggestion would be to follow the jsonapi.org > > spec (http://jsonapi.org/format/) if we decide to do this > > > > GET/articles/1?include=comments.author > > > Given that the current api is not jsonapi compatible (and we need to add > support for this to the existing hosts api), i think it would make sense > to use something similar but more rails-esque, such as: > > /hosts?include[]=puppet&include[]=content > > vs the jsonapi way of: > > /hosts/?include=puppet,content > > I also don't know that we need full relationship support (i.e. > comments.author). > > -Justin >