Split Host Api/Hammer Future Design

Justin_Sherrill · April 23, 2015, 1:28pm

As part of unifying the Host and Content Host within Foreman, we are
looking at ways of making the Host model more extendable. Shimon has
emailed previously about some of the model level changes he is planning
on proposing but has not discussed the api/cli layer. There has also
been some discussion in the past [1].

For the current Foreman V2 api this would not change to ensure api
compatability. But for the Katello System/Content Host Api and
potentially the Foreman V3 api this design is relevant.

I've identified two possible methods of supporting Host extensions
through plugins (or even in core):

Split api/cli

Each plugin/concern would need to implement its own controller and json
serialization (rabl template for example), while the main host route
would handle updates and searching the extended attributes and
relationships:

GET /api/hosts?search="content_view_id=3"
GET /api/hosts/:id/content/
GET /api/hosts/:id/subscription/
GET /api/hosts/:id/salt/
PUT /api/hosts/:id/ -d {'content_view_id': 3}

The concern could also implement Update and any other actions:

PUT /api/hosts/:id/content -d {'content_view_id': 3}
POST /api/hosts/:id/content/some_content_action

Similarly Hammer would need have split commands as well:

hammer host content details --id=3
hammer host content update --content-view=myView

This could be eventually extended to even the Core foreman concerns:

GET /api/hosts/:id/puppet
hammer host puppet update --environment=production --id=3
hammer host puppet run --id=3

Unified api/cli

Foreman would need to expose some plugin api to add attributes to be
rendered with the host json for index and show. The user would request
the normal host api but receive those additional attributes. CUD would
also be handled at the host level.

/api/v2/hosts?search="content_view_id=3"
/api/v2/hosts/:id

hammer host details --id=3
hammer host update --content-view=myView

I tend to favor approach 1), as the host object could grow quite large
and become unwieldy. It does however require more work on the plugin
author side and from the user perspective is a bit less friendly.

Thoughts?

[1] https://github.com/Katello/katello/pull/4976

stbenjam · April 23, 2015, 1:45pm

>
> As part of unifying the Host and Content Host within Foreman, we are looking
> at ways of making the Host model more extendable. Shimon has emailed
> previously about some of the model level changes he is planning on proposing
> but has not discussed the api/cli layer. There has also been some discussion
> in the past [1].
>
> For the current Foreman V2 api this would not change to ensure api
> compatability. But for the Katello System/Content Host Api and potentially
> the Foreman V3 api this design is relevant.
>
> I've identified two possible methods of supporting Host extensions through
> plugins (or even in core):
>
> 1) Split api/cli
>
> Each plugin/concern would need to implement its own controller and json
> serialization (rabl template for example), while the main host route would
> handle updates and searching the extended attributes and relationships:
>
> GET /api/hosts?search="content_view_id=3"
> GET /api/hosts/:id/content/
> GET /api/hosts/:id/subscription/
> GET /api/hosts/:id/salt/
> PUT /api/hosts/:id/ -d {'content_view_id': 3}
>
> The concern could also implement Update and any other actions:
>
> PUT /api/hosts/:id/content -d {'content_view_id': 3}
> POST /api/hosts/:id/content/some_content_action

Would this force you to make multiple calls? What if I want to assign a
Content View and native Foreman attributes in one call? Maybe not so
important in an update scenario, but what if I want to POST a single
JSON document to create a new host?

···

On Thu, Apr 23, 2015 at 09:28:02AM -0400, Justin Sherrill wrote:

Similarly Hammer would need have split commands as well:

hammer host content details --id=3
hammer host content update --content-view=myView

This could be eventually extended to even the Core foreman concerns:

GET /api/hosts/:id/puppet
hammer host puppet update --environment=production --id=3
hammer host puppet run --id=3

Unified api/cli

Foreman would need to expose some plugin api to add attributes to be
rendered with the host json for index and show. The user would request the
normal host api but receive those additional attributes. CUD would also be
handled at the host level.

/api/v2/hosts?search=“content_view_id=3”
/api/v2/hosts/:id

hammer host details --id=3
hammer host update --content-view=myView

I tend to favor approach 1), as the host object could grow quite large and
become unwieldy. It does however require more work on the plugin author
side and from the user perspective is a bit less friendly.

Thoughts?

[1] https://github.com/Katello/katello/pull/4976

–
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.

ehelms · April 24, 2015, 1:32pm

>
> As part of unifying the Host and Content Host within Foreman, we are
> looking at ways of making the Host model more extendable. Shimon has
> emailed previously about some of the model level changes he is planning on
> proposing but has not discussed the api/cli layer. There has also been some
> discussion in the past [1].
>
> For the current Foreman V2 api this would not change to ensure api
> compatability. But for the Katello System/Content Host Api and potentially
> the Foreman V3 api this design is relevant.
>
> I've identified two possible methods of supporting Host extensions through
> plugins (or even in core):
>
> 1) Split api/cli
>
> Each plugin/concern would need to implement its own controller and json
> serialization (rabl template for example), while the main host route would
> handle updates and searching the extended attributes and relationships:
>
> GET /api/hosts?search="content_view_id=3"
> GET /api/hosts/:id/content/
> GET /api/hosts/:id/subscription/
> GET /api/hosts/:id/salt/
> PUT /api/hosts/:id/ -d {'content_view_id': 3}
>

This seems clean from a separation of concerns and extensibility point of
view. And as you said, I would worry that host objects would become quite
large. Did you consider doing this through parameters and/instead of
through routes? For example:

GET /api/hosts/1?include[]=content&include[]=subscription

Eric

···

On Thu, Apr 23, 2015 at 9:28 AM, Justin Sherrill wrote:

The concern could also implement Update and any other actions:

PUT /api/hosts/:id/content -d {‘content_view_id’: 3}
POST /api/hosts/:id/content/some_content_action

Similarly Hammer would need have split commands as well:

hammer host content details --id=3
hammer host content update --content-view=myView

This could be eventually extended to even the Core foreman concerns:

GET /api/hosts/:id/puppet
hammer host puppet update --environment=production --id=3
hammer host puppet run --id=3

Unified api/cli

Foreman would need to expose some plugin api to add attributes to be
rendered with the host json for index and show. The user would request the
normal host api but receive those additional attributes. CUD would also be
handled at the host level.

/api/v2/hosts?search=“content_view_id=3”
/api/v2/hosts/:id

hammer host details --id=3
hammer host update --content-view=myView

I tend to favor approach 1), as the host object could grow quite large and
become unwieldy. It does however require more work on the plugin author
side and from the user perspective is a bit less friendly.

Thoughts?

[1] https://github.com/Katello/katello/pull/4976

–
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.

Justin_Sherrill · April 23, 2015, 2:12pm

>> As part of unifying the Host and Content Host within Foreman, we are looking
>> at ways of making the Host model more extendable. Shimon has emailed
>> previously about some of the model level changes he is planning on proposing
>> but has not discussed the api/cli layer. There has also been some discussion
>> in the past [1].
>>
>> For the current Foreman V2 api this would not change to ensure api
>> compatability. But for the Katello System/Content Host Api and potentially
>> the Foreman V3 api this design is relevant.
>>
>> I've identified two possible methods of supporting Host extensions through
>> plugins (or even in core):
>>
>> 1) Split api/cli
>>
>> Each plugin/concern would need to implement its own controller and json
>> serialization (rabl template for example), while the main host route would
>> handle updates and searching the extended attributes and relationships:
>>
>> GET /api/hosts?search="content_view_id=3"
>> GET /api/hosts/:id/content/
>> GET /api/hosts/:id/subscription/
>> GET /api/hosts/:id/salt/
>> PUT /api/hosts/:id/ -d {'content_view_id': 3}
>>
>> The concern could also implement Update and any other actions:
>>
>> PUT /api/hosts/:id/content -d {'content_view_id': 3}
>> POST /api/hosts/:id/content/some_content_action
> Would this force you to make multiple calls? What if I want to assign a
> Content View and native Foreman attributes in one call? Maybe not so
> important in an update scenario, but what if I want to POST a single
> JSON document to create a new host?
With Shimon's model design you could mix concern attributes in a single
call:

PUT /api/hosts/:id -d {'content_view_id': 3, 'salt_environment':
'bob', 'name': 'mary.example.com'}

within the same call. Simple attribute/association updates could be
handled centrally.

···

On 04/23/2015 09:45 AM, Stephen Benjamin wrote: > On Thu, Apr 23, 2015 at 09:28:02AM -0400, Justin Sherrill wrote:

Similarly Hammer would need have split commands as well:

hammer host content details --id=3
hammer host content update --content-view=myView

This could be eventually extended to even the Core foreman concerns:

GET /api/hosts/:id/puppet
hammer host puppet update --environment=production --id=3
hammer host puppet run --id=3

Unified api/cli

Foreman would need to expose some plugin api to add attributes to be
rendered with the host json for index and show. The user would request the
normal host api but receive those additional attributes. CUD would also be
handled at the host level.

/api/v2/hosts?search=“content_view_id=3”
/api/v2/hosts/:id

hammer host details --id=3
hammer host update --content-view=myView

I tend to favor approach 1), as the host object could grow quite large and
become unwieldy. It does however require more work on the plugin author
side and from the user perspective is a bit less friendly.

Thoughts?

[1] https://github.com/Katello/katello/pull/4976

–
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.

Justin_Sherrill · April 23, 2015, 2:13pm

>>> As part of unifying the Host and Content Host within Foreman, we are
>>> looking
>>> at ways of making the Host model more extendable. Shimon has emailed
>>> previously about some of the model level changes he is planning on
>>> proposing
>>> but has not discussed the api/cli layer. There has also been some
>>> discussion
>>> in the past [1].
>>>
>>> For the current Foreman V2 api this would not change to ensure api
>>> compatability. But for the Katello System/Content Host Api and
>>> potentially
>>> the Foreman V3 api this design is relevant.
>>>
>>> I've identified two possible methods of supporting Host extensions
>>> through
>>> plugins (or even in core):
>>>
>>> 1) Split api/cli
>>>
>>> Each plugin/concern would need to implement its own controller and json
>>> serialization (rabl template for example), while the main host route
>>> would
>>> handle updates and searching the extended attributes and relationships:
>>>
>>> GET /api/hosts?search="content_view_id=3"
>>> GET /api/hosts/:id/content/
>>> GET /api/hosts/:id/subscription/
>>> GET /api/hosts/:id/salt/
>>> PUT /api/hosts/:id/ -d {'content_view_id': 3}
>>>
>>> The concern could also implement Update and any other actions:
>>>
>>> PUT /api/hosts/:id/content -d {'content_view_id': 3}
>>> POST /api/hosts/:id/content/some_content_action
>> Would this force you to make multiple calls? What if I want to assign a
>> Content View and native Foreman attributes in one call? Maybe not so
>> important in an update scenario, but what if I want to POST a single
>> JSON document to create a new host?
> With Shimon's model design you could mix concern attributes in a
> single call:
>
> PUT /api/hosts/:id -d {'content_view_id': 3, 'salt_environment':
> 'bob', 'name': 'mary.example.com'}
>
> within the same call. Simple attribute/association updates could be
> handled centrally.
Hit send too quickly. The same would be true for Create.

···

On 04/23/2015 10:12 AM, Justin Sherrill wrote: > On 04/23/2015 09:45 AM, Stephen Benjamin wrote: >> On Thu, Apr 23, 2015 at 09:28:02AM -0400, Justin Sherrill wrote:

Similarly Hammer would need have split commands as well:

hammer host content details --id=3
hammer host content update --content-view=myView

This could be eventually extended to even the Core foreman concerns:

GET /api/hosts/:id/puppet
hammer host puppet update --environment=production --id=3
hammer host puppet run --id=3

Unified api/cli

Foreman would need to expose some plugin api to add attributes to be
rendered with the host json for index and show. The user would
request the
normal host api but receive those additional attributes. CUD would
also be
handled at the host level.

/api/v2/hosts?search=“content_view_id=3”
/api/v2/hosts/:id

hammer host details --id=3
hammer host update --content-view=myView

I tend to favor approach 1), as the host object could grow quite
large and
become unwieldy. It does however require more work on the plugin
author
side and from the user perspective is a bit less friendly.

Thoughts?

[1] https://github.com/Katello/katello/pull/4976

–
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.

Justin_Sherrill · April 28, 2015, 12:59am

>
>
>
>
> As part of unifying the Host and Content Host within Foreman, we
> are looking at ways of making the Host model more extendable.
> Shimon has emailed previously about some of the model level
> changes he is planning on proposing but has not discussed the
> api/cli layer. There has also been some discussion in the past [1].
>
> For the current Foreman V2 api this would not change to ensure api
> compatability. But for the Katello System/Content Host Api and
> potentially the Foreman V3 api this design is relevant.
>
> I've identified two possible methods of supporting Host extensions
> through plugins (or even in core):
>
> 1) Split api/cli
>
> Each plugin/concern would need to implement its own controller and
> json serialization (rabl template for example), while the main
> host route would handle updates and searching the extended
> attributes and relationships:
>
> GET /api/hosts?search="content_view_id=3"
> GET /api/hosts/:id/content/
> GET /api/hosts/:id/subscription/
> GET /api/hosts/:id/salt/
> PUT /api/hosts/:id/ -d {'content_view_id': 3}
>
>
> This seems clean from a separation of concerns and extensibility point
> of view. And as you said, I would worry that host objects would become
> quite large. Did you consider doing this through parameters
> and/instead of through routes? For example:
>
> GET /api/hosts/1?include[]=content&include[]=subscription
If we went the 2nd route described below (plugin points to extend the
apipie parameters and rabl), that may be an option to trim down the size
of the 'host'. I do kind of like that if we take that route, but I
still think i prefer the split out design.

-Justin

···

On 04/24/2015 09:32 AM, Eric D Helms wrote: > On Thu, Apr 23, 2015 at 9:28 AM, Justin Sherrill > wrote:

Eric

The concern could also implement Update and any other actions:

PUT /api/hosts/:id/content  -d {'content_view_id': 3}
POST /api/hosts/:id/content/some_content_action

Similarly Hammer would need have split commands as well:

hammer host content details --id=3
hammer host content update --content-view=myView

This could be eventually extended to even the Core foreman concerns:

  GET /api/hosts/:id/puppet
  hammer host puppet update --environment=production --id=3
  hammer host puppet run --id=3


2) Unified api/cli

Foreman would need to expose some plugin api to add attributes to
be rendered with the host json for index and show.  The user would
request the normal host api but receive those additional
attributes.  CUD would also be handled at the host level.

/api/v2/hosts?search="content_view_id=3"
/api/v2/hosts/:id

hammer host details --id=3
hammer host update --content-view=myView


I tend to favor approach 1), as the host object could grow quite
large and become unwieldy.  It does however require more work on
the plugin author side and from the user perspective is a bit less
friendly.

Thoughts?


[1] https://github.com/Katello/katello/pull/4976

-- 
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.

Justin_Sherrill · April 28, 2015, 4:46pm

>>>> As part of unifying the Host and Content Host within Foreman, we
>>>> are looking
>>>> at ways of making the Host model more extendable. Shimon has emailed
>>>> previously about some of the model level changes he is planning on
>>>> proposing
>>>> but has not discussed the api/cli layer. There has also been some
>>>> discussion
>>>> in the past [1].
>>>>
>>>> For the current Foreman V2 api this would not change to ensure api
>>>> compatability. But for the Katello System/Content Host Api and
>>>> potentially
>>>> the Foreman V3 api this design is relevant.
>>>>
>>>> I've identified two possible methods of supporting Host extensions
>>>> through
>>>> plugins (or even in core):
>>>>
>>>> 1) Split api/cli
>>>>
>>>> Each plugin/concern would need to implement its own controller and
>>>> json
>>>> serialization (rabl template for example), while the main host
>>>> route would
>>>> handle updates and searching the extended attributes and
>>>> relationships:
>>>>
>>>> GET /api/hosts?search="content_view_id=3"
>>>> GET /api/hosts/:id/content/
>>>> GET /api/hosts/:id/subscription/
>>>> GET /api/hosts/:id/salt/
>>>> PUT /api/hosts/:id/ -d {'content_view_id': 3}
>>>>
>>>> The concern could also implement Update and any other actions:
>>>>
>>>> PUT /api/hosts/:id/content -d {'content_view_id': 3}
>>>> POST /api/hosts/:id/content/some_content_action
>>> Would this force you to make multiple calls? What if I want to assign a
>>> Content View and native Foreman attributes in one call? Maybe not so
>>> important in an update scenario, but what if I want to POST a single
>>> JSON document to create a new host?
>> With Shimon's model design you could mix concern attributes in a
>> single call:
>>
>> PUT /api/hosts/:id -d {'content_view_id': 3, 'salt_environment':
>> 'bob', 'name': 'mary.example.com'}
>>
>> within the same call. Simple attribute/association updates could be
>> handled centrally.
> Hit send too quickly. The same would be true for Create.
>
On aspect I did not discuss was the need to orchestrate to backend
services for host creation/updating/deleting when katello is in play.

My thought was to wrap the existing Host#save, Host#destroy, &
Host#update_attributes calls within the various host controllers within
a dynflow action. This would not move any of the existing orchestration
to dynflow but would simply move those specific AR method calls into a
dynflow action.

I know there is still a long road to having dynflow into foreman, so my
initial thought was to simply override the create/update/delete actions
in the 3 hosts controllers (hosts, v1/hosts, v2/hosts) within
foreman-tasks (or possibly within another plugin).

Thoughts on this?

-Justin

···

On 04/23/2015 10:13 AM, Justin Sherrill wrote: > On 04/23/2015 10:12 AM, Justin Sherrill wrote: >> On 04/23/2015 09:45 AM, Stephen Benjamin wrote: >>> On Thu, Apr 23, 2015 at 09:28:02AM -0400, Justin Sherrill wrote: >> >> >>> >>>> Similarly Hammer would need have split commands as well: >>>> >>>> hammer host content details --id=3 >>>> hammer host content update --content-view=myView >>>> >>>> This could be eventually extended to even the Core foreman concerns: >>>> >>>> GET /api/hosts/:id/puppet >>>> hammer host puppet update --environment=production --id=3 >>>> hammer host puppet run --id=3 >>>> >>>> >>>> 2) Unified api/cli >>>> >>>> Foreman would need to expose some plugin api to add attributes to be >>>> rendered with the host json for index and show. The user would >>>> request the >>>> normal host api but receive those additional attributes. CUD would >>>> also be >>>> handled at the host level. >>>> >>>> /api/v2/hosts?search="content_view_id=3" >>>> /api/v2/hosts/:id >>>> >>>> hammer host details --id=3 >>>> hammer host update --content-view=myView >>>> >>>> >>>> I tend to favor approach 1), as the host object could grow quite >>>> large and >>>> become unwieldy. It does however require more work on the plugin >>>> author >>>> side and from the user perspective is a bit less friendly. >>>> >>>> >>>> Thoughts? >>>> >>>> >>>> [1] https://github.com/Katello/katello/pull/4976 >>>> >>>> -- >>>> 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. >> >

Shimon_Shtein · April 30, 2015, 6:38am

About the split API vs unified one:
Why not both?
Every aspect is a different object, and therefore can have a separate
access point in the API. If the user knows which aspect he wants to change

probably it will be easier for him to change it via the dedicated
interface.
From the other side, if the user is not interested in the aspect separation
(or simply doesn't care about it at this moment), he should be able to
change the host as a single atomic unit.
As for the Eric's proposal (about GET
/api/hosts/1?include[]=content&include[]=subscription) for retrieving the
information, I like it very much (I have tried to avoid using buzzwords in
this mail, but could not resist in this case and say that it's the most
RESTful way to do it).

About the integration of Dynflow in various updates:
Be aware that Dynflow has an asynchronous nature, so you will add all the
async complexity into each controller (IMHO managing transactions in async
world is a big mess).
About moving the whole API call to async mode, I probably want to see a use
case that you have in mind. One thing that the user looses is the guarantee
of the state after the update command.

Shimon.

···

On Tuesday, April 28, 2015 at 7:46:29 PM UTC+3, jsherril wrote: > > On 04/23/2015 10:13 AM, Justin Sherrill wrote: > > On 04/23/2015 10:12 AM, Justin Sherrill wrote: > >> On 04/23/2015 09:45 AM, Stephen Benjamin wrote: > >>> On Thu, Apr 23, 2015 at 09:28:02AM -0400, Justin Sherrill wrote: > >>>> As part of unifying the Host and Content Host within Foreman, we > >>>> are looking > >>>> at ways of making the Host model more extendable. Shimon has emailed > >>>> previously about some of the model level changes he is planning on > >>>> proposing > >>>> but has not discussed the api/cli layer. There has also been some > >>>> discussion > >>>> in the past [1]. > >>>> > >>>> For the current Foreman V2 api this would not change to ensure api > >>>> compatability. But for the Katello System/Content Host Api and > >>>> potentially > >>>> the Foreman V3 api this design is relevant. > >>>> > >>>> I've identified two possible methods of supporting Host extensions > >>>> through > >>>> plugins (or even in core): > >>>> > >>>> 1) Split api/cli > >>>> > >>>> Each plugin/concern would need to implement its own controller and > >>>> json > >>>> serialization (rabl template for example), while the main host > >>>> route would > >>>> handle updates and searching the extended attributes and > >>>> relationships: > >>>> > >>>> GET /api/hosts?search="content_view_id=3" > >>>> GET /api/hosts/:id/content/ > >>>> GET /api/hosts/:id/subscription/ > >>>> GET /api/hosts/:id/salt/ > >>>> PUT /api/hosts/:id/ -d {'content_view_id': 3} > >>>> > >>>> The concern could also implement Update and any other actions: > >>>> > >>>> PUT /api/hosts/:id/content -d {'content_view_id': 3} > >>>> POST /api/hosts/:id/content/some_content_action > >>> Would this force you to make multiple calls? What if I want to assign > a > >>> Content View and native Foreman attributes in one call? Maybe not so > >>> important in an update scenario, but what if I want to POST a single > >>> JSON document to create a new host? > >> With Shimon's model design you could mix concern attributes in a > >> single call: > >> > >> PUT /api/hosts/:id -d {'content_view_id': 3, 'salt_environment': > >> 'bob', 'name': 'mary.example.com'} > >> > >> within the same call. Simple attribute/association updates could be > >> handled centrally. > > Hit send too quickly. The same would be true for Create. > > > On aspect I did not discuss was the need to orchestrate to backend > services for host creation/updating/deleting when katello is in play. > > My thought was to wrap the existing Host#save, Host#destroy, & > Host#update_attributes calls within the various host controllers within > a dynflow action. This would not move any of the existing orchestration > to dynflow but would simply move those specific AR method calls into a > dynflow action. > > I know there is still a long road to having dynflow into foreman, so my > initial thought was to simply override the create/update/delete actions > in the 3 hosts controllers (hosts, v1/hosts, v2/hosts) within > foreman-tasks (or possibly within another plugin). > > Thoughts on this? > > -Justin > >> > >> > >>> > >>>> Similarly Hammer would need have split commands as well: > >>>> > >>>> hammer host content details --id=3 > >>>> hammer host content update --content-view=myView > >>>> > >>>> This could be eventually extended to even the Core foreman concerns: > >>>> > >>>> GET /api/hosts/:id/puppet > >>>> hammer host puppet update --environment=production --id=3 > >>>> hammer host puppet run --id=3 > >>>> > >>>> > >>>> 2) Unified api/cli > >>>> > >>>> Foreman would need to expose some plugin api to add attributes to be > >>>> rendered with the host json for index and show. The user would > >>>> request the > >>>> normal host api but receive those additional attributes. CUD would > >>>> also be > >>>> handled at the host level. > >>>> > >>>> /api/v2/hosts?search="content_view_id=3" > >>>> /api/v2/hosts/:id > >>>> > >>>> hammer host details --id=3 > >>>> hammer host update --content-view=myView > >>>> > >>>> > >>>> I tend to favor approach 1), as the host object could grow quite > >>>> large and > >>>> become unwieldy. It does however require more work on the plugin > >>>> author > >>>> side and from the user perspective is a bit less friendly. > >>>> > >>>> > >>>> Thoughts? > >>>> > >>>> > >>>> [1] https://github.com/Katello/katello/pull/4976 > >>>> > >>>> -- > >>>> 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...@googlegroups.com . > >>>> For more options, visit https://groups.google.com/d/optout. > >> > > > >

iNecas · April 30, 2015, 7:56am

> About the split API vs unified one:
> Why not both?
> Every aspect is a different object, and therefore can have a separate
> access point in the API. If the user knows which aspect he wants to change
> - probably it will be easier for him to change it via the dedicated
> interface.

I don't think we got an agreement on every aspect being a separate object.
From the last discussion we had, it seemed like trying to approach the single-host
this way would bring too much unnecessary complexity into the DB schema (unless
you're not talking about having separata db table for each aspect).

> From the other side, if the user is not interested in the aspect separation
> (or simply doesn't care about it at this moment), he should be able to
> change the host as a single atomic unit.
> As for the Eric's proposal (about GET
> /api/hosts/1?include[]=content&include[]=subscription) for retrieving the
> information, I like it very much (I have tried to avoid using buzzwords in
> this mail, but could not resist in this case and say that it's the most
> RESTful way to do it).
>
> About the integration of Dynflow in various updates:
> Be aware that Dynflow has an asynchronous nature, so you will add all the
> async complexity into each controller (IMHO managing transactions in async
> world is a big mess).

The async part is optional and depends on how you define the dynflow actions:
You can have dynflow actions that don't run anything async at all.

IMHO calling to external systems inside the db transaction is the source of mess.
Dynflow

> About moving the whole API call to async mode, I probably want to see a use
> case that you have in mind. One thing that the user looses is the guarantee
> of the state after the update command.

Even with Dynflow, you can make the response act as synchronous even when you use
some async calls inside it.

– Ivan

···

----- Original Message -----

Shimon.

On Tuesday, April 28, 2015 at 7:46:29 PM UTC+3, jsherril wrote:

On 04/23/2015 10:13 AM, Justin Sherrill wrote:

On 04/23/2015 10:12 AM, Justin Sherrill wrote:

On 04/23/2015 09:45 AM, Stephen Benjamin wrote:

On Thu, Apr 23, 2015 at 09:28:02AM -0400, Justin Sherrill wrote:

As part of unifying the Host and Content Host within Foreman, we
are looking
at ways of making the Host model more extendable. Shimon has emailed
previously about some of the model level changes he is planning on
proposing
but has not discussed the api/cli layer. There has also been some
discussion
in the past [1].

For the current Foreman V2 api this would not change to ensure api
compatability. But for the Katello System/Content Host Api and
potentially
the Foreman V3 api this design is relevant.

I’ve identified two possible methods of supporting Host extensions
through
plugins (or even in core):

Split api/cli

Each plugin/concern would need to implement its own controller and
json
serialization (rabl template for example), while the main host
route would
handle updates and searching the extended attributes and
relationships:

GET /api/hosts?search="content_view_id=3"
GET /api/hosts/:id/content/
GET /api/hosts/:id/subscription/
GET /api/hosts/:id/salt/
PUT /api/hosts/:id/ -d {‘content_view_id’: 3}

The concern could also implement Update and any other actions:

PUT /api/hosts/:id/content -d {‘content_view_id’: 3}
POST /api/hosts/:id/content/some_content_action
Would this force you to make multiple calls? What if I want to assign
a

Content View and native Foreman attributes in one call? Maybe not so
important in an update scenario, but what if I want to POST a single
JSON document to create a new host?
With Shimon’s model design you could mix concern attributes in a
single call:

PUT /api/hosts/:id -d {‘content_view_id’: 3, ‘salt_environment’:
‘bob’, ‘name’: ‘mary.example.com’}

within the same call. Simple attribute/association updates could be
handled centrally.
Hit send too quickly. The same would be true for Create.

On aspect I did not discuss was the need to orchestrate to backend
services for host creation/updating/deleting when katello is in play.

My thought was to wrap the existing Host#save, Host#destroy, &
Host#update_attributes calls within the various host controllers within
a dynflow action. This would not move any of the existing orchestration
to dynflow but would simply move those specific AR method calls into a
dynflow action.

I know there is still a long road to having dynflow into foreman, so my
initial thought was to simply override the create/update/delete actions
in the 3 hosts controllers (hosts, v1/hosts, v2/hosts) within
foreman-tasks (or possibly within another plugin).

Thoughts on this?

-Justin

Similarly Hammer would need have split commands as well:

hammer host content details --id=3
hammer host content update --content-view=myView

This could be eventually extended to even the Core foreman concerns:

GET /api/hosts/:id/puppet
hammer host puppet update --environment=production --id=3
hammer host puppet run --id=3

Unified api/cli

Foreman would need to expose some plugin api to add attributes to be
rendered with the host json for index and show. The user would
request the
normal host api but receive those additional attributes. CUD would
also be
handled at the host level.

/api/v2/hosts?search=“content_view_id=3”
/api/v2/hosts/:id

hammer host details --id=3
hammer host update --content-view=myView

I tend to favor approach 1), as the host object could grow quite
large and
become unwieldy. It does however require more work on the plugin
author
side and from the user perspective is a bit less friendly.

Thoughts?

[1] https://github.com/Katello/katello/pull/4976

–
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...@googlegroups.com <javascript:>.
For more options, visit https://groups.google.com/d/optout.

Justin_Sherrill · May 4, 2015, 12:50pm

> About the split API vs unified one:
> Why not both?
> Every aspect is a different object, and therefore can have a separate
> access point in the API. If the user knows which aspect he wants to
> change - probably it will be easier for him to change it via the
> dedicated interface.

With the split proposal you could update the attributes from either, but
the split out space would provide an area for additional rest actions,
such as in the katello use case:

GET /api/v2/host/:id/content/package_profile (retrieving the package
profile of a host)
PUT /api/v2/host/:id/content/packages/install (installing a package
on a host)

It would also provide a place for you to get the attributes of that aspect:

GET /api/v2/host/:id/content

From the other side, if the user is not interested in the aspect
separation (or simply doesn't care about it at this moment), he should
be able to change the host as a single atomic unit.
> As for the Eric's proposal (about GET
> /api/hosts/1?include[]=content&include[]=subscription) for retrieving
> the information, I like it very much (I have tried to avoid using
> buzzwords in this mail, but could not resist in this case and say that
> it's the most RESTful way to do it).

I'm not opposed to this method, it is basically the unified method i
proposed with a way to trim down the details you get back. It still
requires a supported plugin api to extend a controllers apipie docs and
rabl. Since there had been some views expressed against that in the
past, i was hoping to get more feedback around that

>
> About the integration of Dynflow in various updates:
> Be aware that Dynflow has an asynchronous nature, so you will add all
> the async complexity into each controller (IMHO managing transactions
> in async world is a big mess).
> About moving the whole API call to async mode, I probably want to see
> a use case that you have in mind. One thing that the user looses is
> the guarantee of the state after the update command.
As ivan said, you can choose at execution time whether to run a task
synchronously or not. Here's an example of a synchronous create():

https://github.com/Katello/katello/blob/master/app/controllers/katello/api/v2/systems_controller.rb#L128

Most create and update actions in katello are synchronous.

-Justin

···

On 04/30/2015 02:38 AM, Shim Shtein wrote:

Shimon.

On Tuesday, April 28, 2015 at 7:46:29 PM UTC+3, jsherril wrote:

On 04/23/2015 10:13 AM, Justin Sherrill wrote:
> On 04/23/2015 10:12 AM, Justin Sherrill wrote:
>> On 04/23/2015 09:45 AM, Stephen Benjamin wrote:
>>> On Thu, Apr 23, 2015 at 09:28:02AM -0400, Justin Sherrill wrote:
>>>> As part of unifying the Host and Content Host within Foreman, we
>>>> are looking
>>>> at ways of making the Host model more extendable.  Shimon has
emailed
>>>> previously about some of the model level changes he is
planning on
>>>> proposing
>>>> but has not discussed the api/cli layer. There has also been
some
>>>> discussion
>>>> in the past [1].
>>>>
>>>> For the current Foreman V2 api this would not change to
ensure api
>>>> compatability.  But for the Katello System/Content Host Api and
>>>> potentially
>>>> the Foreman V3 api this design is relevant.
>>>>
>>>> I've identified two possible methods of supporting Host
extensions
>>>> through
>>>> plugins (or even in core):
>>>>
>>>> 1) Split api/cli
>>>>
>>>> Each plugin/concern would need to implement its own
controller and
>>>> json
>>>> serialization (rabl template for example), while the main host
>>>> route would
>>>> handle updates and searching the extended attributes and
>>>> relationships:
>>>>
>>>> GET   /api/hosts?search="content_view_id=3"
>>>> GET   /api/hosts/:id/content/
>>>> GET   /api/hosts/:id/subscription/
>>>> GET   /api/hosts/:id/salt/
>>>> PUT  /api/hosts/:id/    -d {'content_view_id': 3}
>>>>
>>>> The concern could also implement Update and any other actions:
>>>>
>>>> PUT /api/hosts/:id/content  -d {'content_view_id': 3}
>>>> POST /api/hosts/:id/content/some_content_action
>>> Would this force you to make multiple calls? What if I want to
assign a
>>> Content View and native Foreman attributes in one call?  Maybe
not so
>>> important in an update scenario, but what if I want to POST a
single
>>> JSON document to create a new host?
>> With Shimon's model design you could mix concern attributes in a
>> single call:
>>
>> PUT /api/hosts/:id   -d {'content_view_id': 3, 'salt_environment':
>> 'bob', 'name': 'mary.example.com <http://mary.example.com>'}
>>
>> within the same call.  Simple attribute/association updates
could be
>> handled centrally.
> Hit send too quickly.  The same would be true for Create.
>
On aspect I did not discuss was the need to orchestrate to backend
services for host creation/updating/deleting when katello is in play.

My thought was to wrap the existing Host#save, Host#destroy, &
Host#update_attributes calls within the various host controllers
within
a dynflow action.  This would not move any of the existing
orchestration
to dynflow but would simply move those specific AR method calls
into a
dynflow action.

I know there is still a long road to having dynflow into foreman,
so my
initial thought was to simply override the create/update/delete
actions
in the 3 hosts controllers (hosts, v1/hosts, v2/hosts) within
foreman-tasks (or possibly within another plugin).

Thoughts on this?

-Justin
>>
>>
>>>
>>>> Similarly Hammer would need have split commands as well:
>>>>
>>>> hammer host content details --id=3
>>>> hammer host content update --content-view=myView
>>>>
>>>> This could be eventually extended to even the Core foreman
concerns:
>>>>
>>>>    GET /api/hosts/:id/puppet
>>>>    hammer host puppet update --environment=production --id=3
>>>>    hammer host puppet run --id=3
>>>>
>>>>
>>>> 2) Unified api/cli
>>>>
>>>> Foreman would need to expose some plugin api to add
attributes to be
>>>> rendered with the host json for index and show.  The user would
>>>> request the
>>>> normal host api but receive those additional attributes. CUD
would
>>>> also be
>>>> handled at the host level.
>>>>
>>>> /api/v2/hosts?search="content_view_id=3"
>>>> /api/v2/hosts/:id
>>>>
>>>> hammer host details --id=3
>>>> hammer host update --content-view=myView
>>>>
>>>>
>>>> I tend to favor approach 1), as the host object could grow quite
>>>> large and
>>>> become unwieldy.  It does however require more work on the
plugin
>>>> author
>>>> side and from the user perspective is a bit less friendly.
>>>>
>>>>
>>>> Thoughts?
>>>>
>>>>
>>>> [1] https://github.com/Katello/katello/pull/4976
<https://github.com/Katello/katello/pull/4976>
>>>>
>>>> --
>>>> 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...@googlegroups.com <javascript:>.
>>>> For more options, visit https://groups.google.com/d/optout
<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.

Walden_Raines · November 10, 2015, 3:12pm

Hey,

Apologies for reviving this thread, I somehow missed it originally and this issue has come up for me during the work on my PR [1] to move packages from systems to hosts.

I'm personally in favor of just adding the sub-resources directly to the base resource object, without the split. In other words:

/host/:id/puppet-classes
/host/:id/packages

vs

/host/:id/puppet/classes
/host/:id/content/packages

The main reason being that you cannot CRUD /host/:id/puppet or /host/:id/content; puppet and content are not resources, they are an arbitrary (and somewhat meaningless to our users) grouping of aspects (or facets?). I think that consumers of our APIs will be confused about the superfluous /content or /puppet and this pattern is also contrary to every other REST API I have seen.

Thoughts?

Cheers,
Walden

[1] https://github.com/Katello/katello/pull/5575

···

----- Original Message ----- From: "Justin Sherrill" To: foreman-dev@googlegroups.com Sent: Monday, May 4, 2015 8:50:06 AM Subject: Re: [foreman-dev] Split Host Api/Hammer Future Design

On 04/30/2015 02:38 AM, Shim Shtein wrote:

About the split API vs unified one:
Why not both?
Every aspect is a different object, and therefore can have a separate
access point in the API. If the user knows which aspect he wants to
change - probably it will be easier for him to change it via the
dedicated interface.

With the split proposal you could update the attributes from either, but
the split out space would provide an area for additional rest actions,
such as in the katello use case:

GET /api/v2/host/:id/content/package_profile (retrieving the package
profile of a host)
PUT /api/v2/host/:id/content/packages/install (installing a package
on a host)

It would also provide a place for you to get the attributes of that aspect:

GET /api/v2/host/:id/content

From the other side, if the user is not interested in the aspect
separation (or simply doesn’t care about it at this moment), he should
be able to change the host as a single atomic unit.

As for the Eric’s proposal (about GET
/api/hosts/1?include[]=content&include[]=subscription) for retrieving
the information, I like it very much (I have tried to avoid using
buzzwords in this mail, but could not resist in this case and say that
it’s the most RESTful way to do it).

I’m not opposed to this method, it is basically the unified method i
proposed with a way to trim down the details you get back. It still
requires a supported plugin api to extend a controllers apipie docs and
rabl. Since there had been some views expressed against that in the
past, i was hoping to get more feedback around that

About the integration of Dynflow in various updates:
Be aware that Dynflow has an asynchronous nature, so you will add all
the async complexity into each controller (IMHO managing transactions
in async world is a big mess).
About moving the whole API call to async mode, I probably want to see
a use case that you have in mind. One thing that the user looses is
the guarantee of the state after the update command.
As ivan said, you can choose at execution time whether to run a task
synchronously or not. Here’s an example of a synchronous create():

https://github.com/Katello/katello/blob/master/app/controllers/katello/api/v2/systems_controller.rb#L128

Most create and update actions in katello are synchronous.

-Justin

Shimon.

On Tuesday, April 28, 2015 at 7:46:29 PM UTC+3, jsherril wrote:

On 04/23/2015 10:13 AM, Justin Sherrill wrote:
> On 04/23/2015 10:12 AM, Justin Sherrill wrote:
>> On 04/23/2015 09:45 AM, Stephen Benjamin wrote:
>>> On Thu, Apr 23, 2015 at 09:28:02AM -0400, Justin Sherrill wrote:
>>>> As part of unifying the Host and Content Host within Foreman, we
>>>> are looking
>>>> at ways of making the Host model more extendable.  Shimon has
emailed
>>>> previously about some of the model level changes he is
planning on
>>>> proposing
>>>> but has not discussed the api/cli layer. There has also been
some
>>>> discussion
>>>> in the past [1].
>>>>
>>>> For the current Foreman V2 api this would not change to
ensure api
>>>> compatability.  But for the Katello System/Content Host Api and
>>>> potentially
>>>> the Foreman V3 api this design is relevant.
>>>>
>>>> I've identified two possible methods of supporting Host
extensions
>>>> through
>>>> plugins (or even in core):
>>>>
>>>> 1) Split api/cli
>>>>
>>>> Each plugin/concern would need to implement its own
controller and
>>>> json
>>>> serialization (rabl template for example), while the main host
>>>> route would
>>>> handle updates and searching the extended attributes and
>>>> relationships:
>>>>
>>>> GET   /api/hosts?search="content_view_id=3"
>>>> GET   /api/hosts/:id/content/
>>>> GET   /api/hosts/:id/subscription/
>>>> GET   /api/hosts/:id/salt/
>>>> PUT  /api/hosts/:id/    -d {'content_view_id': 3}
>>>>
>>>> The concern could also implement Update and any other actions:
>>>>
>>>> PUT /api/hosts/:id/content  -d {'content_view_id': 3}
>>>> POST /api/hosts/:id/content/some_content_action
>>> Would this force you to make multiple calls? What if I want to
assign a
>>> Content View and native Foreman attributes in one call?  Maybe
not so
>>> important in an update scenario, but what if I want to POST a
single
>>> JSON document to create a new host?
>> With Shimon's model design you could mix concern attributes in a
>> single call:
>>
>> PUT /api/hosts/:id   -d {'content_view_id': 3, 'salt_environment':
>> 'bob', 'name': 'mary.example.com <http://mary.example.com>'}
>>
>> within the same call.  Simple attribute/association updates
could be
>> handled centrally.
> Hit send too quickly.  The same would be true for Create.
>
On aspect I did not discuss was the need to orchestrate to backend
services for host creation/updating/deleting when katello is in play.

My thought was to wrap the existing Host#save, Host#destroy, &
Host#update_attributes calls within the various host controllers
within
a dynflow action.  This would not move any of the existing
orchestration
to dynflow but would simply move those specific AR method calls
into a
dynflow action.

I know there is still a long road to having dynflow into foreman,
so my
initial thought was to simply override the create/update/delete
actions
in the 3 hosts controllers (hosts, v1/hosts, v2/hosts) within
foreman-tasks (or possibly within another plugin).

Thoughts on this?

-Justin
>>
>>
>>>
>>>> Similarly Hammer would need have split commands as well:
>>>>
>>>> hammer host content details --id=3
>>>> hammer host content update --content-view=myView
>>>>
>>>> This could be eventually extended to even the Core foreman
concerns:
>>>>
>>>>    GET /api/hosts/:id/puppet
>>>>    hammer host puppet update --environment=production --id=3
>>>>    hammer host puppet run --id=3
>>>>
>>>>
>>>> 2) Unified api/cli
>>>>
>>>> Foreman would need to expose some plugin api to add
attributes to be
>>>> rendered with the host json for index and show.  The user would
>>>> request the
>>>> normal host api but receive those additional attributes. CUD
would
>>>> also be
>>>> handled at the host level.
>>>>
>>>> /api/v2/hosts?search="content_view_id=3"
>>>> /api/v2/hosts/:id
>>>>
>>>> hammer host details --id=3
>>>> hammer host update --content-view=myView
>>>>
>>>>
>>>> I tend to favor approach 1), as the host object could grow quite
>>>> large and
>>>> become unwieldy.  It does however require more work on the
plugin
>>>> author
>>>> side and from the user perspective is a bit less friendly.
>>>>
>>>>
>>>> Thoughts?
>>>>
>>>>
>>>> [1] https://github.com/Katello/katello/pull/4976
<https://github.com/Katello/katello/pull/4976>
>>>>
>>>> --
>>>> 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...@googlegroups.com <javascript:>.
>>>> For more options, visit https://groups.google.com/d/optout
<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.

–
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.

thomasmckay · November 10, 2015, 9:21pm

I too would prefer not having sub-resources.

First, I don't want to try to get the existing foreman APIs to change their structure. Katello influence on core foreman has never been smooth and the topic of the API has already been thrashed about over the past couple years. Putting the details directly onto the host API means foreman doesn't need to change and things can progress.

Second, the reason for this host unification work is to allow the host object to be thought of as a single object. If API routes are going to be segregated off by topic (assuming my first point is proven to be incorrect) then it is just exposing implementation details to the user. For example, there are certainly going to be attributes that bleed between two facets and I'd rather see the PUT /hosts/$id be able to work with a single call versus multiple.

···

----- Original Message ----- > Hey, > > Apologies for reviving this thread, I somehow missed it originally and this > issue has come up for me during the work on my PR [1] to move packages from > systems to hosts. > > I'm personally in favor of just adding the sub-resources directly to the base > resource object, without the split. In other words: > > /host/:id/puppet-classes > /host/:id/packages > > vs > > /host/:id/puppet/classes > /host/:id/content/packages > > The main reason being that you cannot CRUD /host/:id/puppet or > /host/:id/content; puppet and content are not resources, they are an > arbitrary (and somewhat meaningless to our users) grouping of aspects (or > facets?). I think that consumers of our APIs will be confused about the > superfluous /content or /puppet and this pattern is also contrary to every > other REST API I have seen. > > Thoughts? > > Cheers, > Walden > > [1] https://github.com/Katello/katello/pull/5575 > > >

daviddavis · November 10, 2015, 10:18pm

I tend to like the unified/no subresources approach better as it seems less
cluttered and a lot simpler. However, my concern would be what do we do
about conflicts? Suppose Foreman implements a host action (eg packages,
puppet-classes, etc) that Katello is already defining. If a conflict does
arise and Katello has to use another route, that’s going to be problematic
in that Katello is suppose to maintain backwards compatibility in its API
between releases. If we have subresources I think a conflict would be less
likely.

David

···

On Tue, Nov 10, 2015 at 4:21 PM, Tom McKay wrote:

----- Original Message -----

Hey,

Apologies for reviving this thread, I somehow missed it originally and
this
issue has come up for me during the work on my PR [1] to move packages
from
systems to hosts.

I’m personally in favor of just adding the sub-resources directly to the
base
resource object, without the split. In other words:

/host/:id/puppet-classes
/host/:id/packages

vs

/host/:id/puppet/classes
/host/:id/content/packages

The main reason being that you cannot CRUD /host/:id/puppet or
/host/:id/content; puppet and content are not resources, they are an
arbitrary (and somewhat meaningless to our users) grouping of aspects (or
facets?). I think that consumers of our APIs will be confused about the
superfluous /content or /puppet and this pattern is also contrary to
every
other REST API I have seen.

Thoughts?

Cheers,
Walden

[1] https://github.com/Katello/katello/pull/5575

I too would prefer not having sub-resources.

First, I don’t want to try to get the existing foreman APIs to change
their structure. Katello influence on core foreman has never been smooth
and the topic of the API has already been thrashed about over the past
couple years. Putting the details directly onto the host API means foreman
doesn’t need to change and things can progress.

Second, the reason for this host unification work is to allow the host
object to be thought of as a single object. If API routes are going to be
segregated off by topic (assuming my first point is proven to be incorrect)
then it is just exposing implementation details to the user. For example,
there are certainly going to be attributes that bleed between two facets
and I’d rather see the PUT /hosts/$id be able to work with a single call
versus multiple.

–
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.

Justin_Sherrill · November 10, 2015, 11:17pm

> I tend to like the unified/no subresources approach better as it seems
> less cluttered and a lot simpler. However, my concern would be what do
> we do about conflicts? Suppose Foreman implements a host action (eg
> packages, puppet-classes, etc) that Katello is already defining. If a
> conflict does arise and Katello has to use another route, that’s going
> to be problematic in that Katello is suppose to maintain backwards
> compatibility in its API between releases. If we have subresources I
> think a conflict would be less likely.

I would also add that if a host can have different features/facets
enabled or disabled it would help the user match up which actions
correspond to which facet with a 'namespaced/subresource' approach.
Otherwise a user would have no idea which rest actions correspond with
the 'puppet' facet if the puppet aspect is not enabled for a particular
host.

-Justin

···

On 11/10/2015 05:18 PM, David Davis wrote:

David

On Tue, Nov 10, 2015 at 4:21 PM, Tom McKay <thomasmckay@redhat.com > mailto:thomasmckay@redhat.com> wrote:

----- Original Message -----
> Hey,
>
> Apologies for reviving this thread, I somehow missed it
originally and this
> issue has come up for me during the work on my PR [1] to move
packages from
> systems to hosts.
>
> I'm personally in favor of just adding the sub-resources
directly to the base
> resource object, without the split.  In other words:
>
> /host/:id/puppet-classes
> /host/:id/packages
>
> vs
>
> /host/:id/puppet/classes
> /host/:id/content/packages
>
> The main reason being that you cannot CRUD /host/:id/puppet or
> /host/:id/content; puppet and content are not resources, they are an
> arbitrary (and somewhat meaningless to our users) grouping of
aspects (or
> facets?).  I think that consumers of our APIs will be confused
about the
> superfluous /content or /puppet and this pattern is also
contrary to every
> other REST API I have seen.
>
> Thoughts?
>
> Cheers,
> Walden
>
> [1] https://github.com/Katello/katello/pull/5575
>
>
>

I too would prefer not having sub-resources.

First, I don't want to try to get the existing foreman APIs to
change their structure. Katello influence on core foreman has
never been smooth and the topic of the API has already been
thrashed about over the past couple years. Putting the details
directly onto the host API means foreman doesn't need to change
and things can progress.

Second, the reason for this host unification work is to allow the
host object to be thought of as a single object. If API routes are
going to be segregated off by topic (assuming my first point is
proven to be incorrect) then it is just exposing implementation
details to the user. For example, there are certainly going to be
attributes that bleed between two facets and I'd rather see the
PUT /hosts/$id be able to work with a single call versus multiple.

--
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.

thomasmckay · November 11, 2015, 1:20pm

> > I tend to like the unified/no subresources approach better as it seems
> > less cluttered and a lot simpler. However, my concern would be what do
> > we do about conflicts? Suppose Foreman implements a host action (eg
> > packages, puppet-classes, etc) that Katello is already defining. If a
> > conflict does arise and Katello has to use another route, that’s going
> > to be problematic in that Katello is suppose to maintain backwards
> > compatibility in its API between releases. If we have subresources I
> > think a conflict would be less likely.
>
> I would also add that if a host can have different features/facets
> enabled or disabled it would help the user match up which actions
> correspond to which facet with a 'namespaced/subresource' approach.
> Otherwise a user would have no idea which rest actions correspond with
> the 'puppet' facet if the puppet aspect is not enabled for a particular
> host.
>
> -Justin

As a consumer of a host, I don't think I should have to arbitrarily know if a host has the puppet facet or not.

GET /api/hosts/$id/puppetclass_ids -> []
POST /api/hosts/$id/puppetclass_ids <-- Creates a puppet facet if one doesn't exist yet?

Or do I need to query the host itself to get a "these are your facets" result?

GET /api/hosts/$id -> {facets: {puppet: false, salt: false, chef: false, content: true, subscription: true}}

Even without puppet being true, might I not still have puppet content?

GET /api/hosts/$id/puppet_modules <- Hypothetical route to return puppet from host's lifecycle environment

You are asking me, the user, to know that although it's a single host object it is really several objects (facets) in the tool. And also to know what fields come from which facet, even if they are conceptually related.

Would I have to
GET /api/hosts/$id/puppet
GET /api/hosts/$id/subscription
GET /api/hosts/$id/content
<combine results client side>
POST /api/hosts/$id/puppet
POST /api/hosts/$id/subscription
POST /api/hosts/$id/content

My opinion is that we go all-in and combine hosts. We are, in fact, a single project and community. There won't be name clashes because a PR to either foreman or katello with a clash would be NACKed.

···

----- Original Message ----- > On 11/10/2015 05:18 PM, David Davis wrote:

David

On Tue, Nov 10, 2015 at 4:21 PM, Tom McKay <thomasmckay@redhat.com > > mailto:thomasmckay@redhat.com> wrote:

----- Original Message -----
> Hey,
>
> Apologies for reviving this thread, I somehow missed it
originally and this
> issue has come up for me during the work on my PR [1] to move
packages from
> systems to hosts.
>
> I'm personally in favor of just adding the sub-resources
directly to the base
> resource object, without the split.  In other words:
>
> /host/:id/puppet-classes
> /host/:id/packages
>
> vs
>
> /host/:id/puppet/classes
> /host/:id/content/packages
>
> The main reason being that you cannot CRUD /host/:id/puppet or
> /host/:id/content; puppet and content are not resources, they are an
> arbitrary (and somewhat meaningless to our users) grouping of
aspects (or
> facets?).  I think that consumers of our APIs will be confused
about the
> superfluous /content or /puppet and this pattern is also
contrary to every
> other REST API I have seen.
>
> Thoughts?
>
> Cheers,
> Walden
>
> [1] https://github.com/Katello/katello/pull/5575
>
>
>

I too would prefer not having sub-resources.

First, I don't want to try to get the existing foreman APIs to
change their structure. Katello influence on core foreman has
never been smooth and the topic of the API has already been
thrashed about over the past couple years. Putting the details
directly onto the host API means foreman doesn't need to change
and things can progress.

Second, the reason for this host unification work is to allow the
host object to be thought of as a single object. If API routes are
going to be segregated off by topic (assuming my first point is
proven to be incorrect) then it is just exposing implementation
details to the user. For example, there are certainly going to be
attributes that bleed between two facets and I'd rather see the
PUT /hosts/$id be able to work with a single call versus multiple.

--
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.

–
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.

Shimon_Shtein · November 11, 2015, 1:48pm

I think it would be nice to separate the issue to two:

properties that are returned/modified
actions that are invoked by the user

About properties I would like to see a unified approach:
GET /api/hosts/$id
will return:
{
"name": "my.host.com",
"puppet_attributes":{
"environment": "production"
}
"subscription_attributes": {
"subs_prop1": "val1"
}
}

As an option we can allow direct access point to the facet via:
GET /api/hosts/$id/puppet
will return:
{
"environment": "production"
}
But this is a shortcut, and I don't think it has much of importance…

About the actions, I think it is more important to create obvious
separation. I don't think the user is oblivious to the fact that the host
has many facets that are managed by Foreman. When the user want to perform
some action on the host, he knows pretty clearly what facet the action
belongs to. Let's take as an example puppet run: I think for the user it
would be very clear that he has to POST /hosts/:id/puppet/run. Another
thought is that it is a pretty indicative way to show an error too. If the
host doesn't have puppet, but the user tries to invoke
/hosts/:id/puppet/run, the user should get 404: hosts/:id/puppet does not
exist.
This way we can enjoy both worlds: Unified view on a single host, but
namespaced actions that become clearer.

···

On Wednesday, November 11, 2015 at 3:20:43 PM UTC+2, Tom McKay wrote: > > > > ----- Original Message ----- > > On 11/10/2015 05:18 PM, David Davis wrote: > > > I tend to like the unified/no subresources approach better as it seems > > > less cluttered and a lot simpler. However, my concern would be what do > > > we do about conflicts? Suppose Foreman implements a host action (eg > > > packages, puppet-classes, etc) that Katello is already defining. If a > > > conflict does arise and Katello has to use another route, that’s going > > > to be problematic in that Katello is suppose to maintain backwards > > > compatibility in its API between releases. If we have subresources I > > > think a conflict would be less likely. > > > > I would also add that if a host can have different features/facets > > enabled or disabled it would help the user match up which actions > > correspond to which facet with a 'namespaced/subresource' approach. > > Otherwise a user would have no idea which rest actions correspond with > > the 'puppet' facet if the puppet aspect is not enabled for a particular > > host. > > > > -Justin > > As a consumer of a host, I don't think I should have to arbitrarily know > if a host has the puppet facet or not. > > GET /api/hosts/$id/puppetclass_ids -> [] > POST /api/hosts/$id/puppetclass_ids <-- Creates a puppet facet if one > doesn't exist yet? > > Or do I need to query the host itself to get a "these are your facets" > result? > > GET /api/hosts/$id -> {facets: {puppet: false, salt: false, chef: false, > content: true, subscription: true}} > > Even without puppet being true, might I not still have puppet content? > > GET /api/hosts/$id/puppet_modules <- Hypothetical route to return puppet > from host's lifecycle environment > > You are asking me, the user, to know that although it's a single host > object it is really several objects (facets) in the tool. And also to know > what fields come from which facet, even if they are conceptually related. > > Would I have to > GET /api/hosts/$id/puppet > GET /api/hosts/$id/subscription > GET /api/hosts/$id/content > > POST /api/hosts/$id/puppet > POST /api/hosts/$id/subscription > POST /api/hosts/$id/content > > My opinion is that we go all-in and combine hosts. We are, in fact, a > single project and community. There won't be name clashes because a PR to > either foreman or katello with a clash would be NACKed. > > > > > > > > > > > > David > > > > > > On Tue, Nov 10, 2015 at 4:21 PM, Tom McKay > > > <mailto:thoma...@redhat.com >> wrote: > > > > > > > > > > > > ----- Original Message ----- > > > > Hey, > > > > > > > > Apologies for reviving this thread, I somehow missed it > > > originally and this > > > > issue has come up for me during the work on my PR [1] to move > > > packages from > > > > systems to hosts. > > > > > > > > I'm personally in favor of just adding the sub-resources > > > directly to the base > > > > resource object, without the split. In other words: > > > > > > > > /host/:id/puppet-classes > > > > /host/:id/packages > > > > > > > > vs > > > > > > > > /host/:id/puppet/classes > > > > /host/:id/content/packages > > > > > > > > The main reason being that you cannot CRUD /host/:id/puppet or > > > > /host/:id/content; puppet and content are not resources, they > are an > > > > arbitrary (and somewhat meaningless to our users) grouping of > > > aspects (or > > > > facets?). I think that consumers of our APIs will be confused > > > about the > > > > superfluous /content or /puppet and this pattern is also > > > contrary to every > > > > other REST API I have seen. > > > > > > > > Thoughts? > > > > > > > > Cheers, > > > > Walden > > > > > > > > [1] https://github.com/Katello/katello/pull/5575 > > > > > > > > > > > > > > > > > > I too would prefer not having sub-resources. > > > > > > First, I don't want to try to get the existing foreman APIs to > > > change their structure. Katello influence on core foreman has > > > never been smooth and the topic of the API has already been > > > thrashed about over the past couple years. Putting the details > > > directly onto the host API means foreman doesn't need to change > > > and things can progress. > > > > > > Second, the reason for this host unification work is to allow the > > > host object to be thought of as a single object. If API routes are > > > going to be segregated off by topic (assuming my first point is > > > proven to be incorrect) then it is just exposing implementation > > > details to the user. For example, there are certainly going to be > > > attributes that bleed between two facets and I'd rather see the > > > PUT /hosts/$id be able to work with a single call versus multiple. > > > > > > -- > > > 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...@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...@googlegroups.com > > > <mailto:foreman-dev+unsubscribe@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...@googlegroups.com . > > For more options, visit https://groups.google.com/d/optout. > > >

Justin_Sherrill · November 11, 2015, 4:08pm

>
>>> I tend to like the unified/no subresources approach better as it seems
>>> less cluttered and a lot simpler. However, my concern would be what do
>>> we do about conflicts? Suppose Foreman implements a host action (eg
>>> packages, puppet-classes, etc) that Katello is already defining. If a
>>> conflict does arise and Katello has to use another route, that’s going
>>> to be problematic in that Katello is suppose to maintain backwards
>>> compatibility in its API between releases. If we have subresources I
>>> think a conflict would be less likely.
>> I would also add that if a host can have different features/facets
>> enabled or disabled it would help the user match up which actions
>> correspond to which facet with a 'namespaced/subresource' approach.
>> Otherwise a user would have no idea which rest actions correspond with
>> the 'puppet' facet if the puppet aspect is not enabled for a particular
>> host.
>>
>> -Justin
> As a consumer of a host, I don't think I should have to arbitrarily know if a host has the puppet facet or not.
>
> GET /api/hosts/$id/puppetclass_ids -> []
> POST /api/hosts/$id/puppetclass_ids <-- Creates a puppet facet if one doesn't exist yet?
>
> Or do I need to query the host itself to get a "these are your facets" result?
>
> GET /api/hosts/$id -> {facets: {puppet: false, salt: false, chef: false, content: true, subscription: true}}
>
> Even without puppet being true, might I not still have puppet content?
There's no such thing as 'having puppet content', but even if there were
I would imagine that'd be under the content aspect.

>
> GET /api/hosts/$id/puppet_modules <- Hypothetical route to return puppet from host's lifecycle environment
>
> You are asking me, the user, to know that although it's a single host object it is really several objects (facets) in the tool. And also to know what fields come from which facet, even if they are conceptually related.

It not knowing about where to get fields/attributes, its more to do with
other actions.
>
> Would I have to
> GET /api/hosts/$id/puppet
> GET /api/hosts/$id/subscription
> GET /api/hosts/$id/content
> <combine results client side>
> POST /api/hosts/$id/puppet
> POST /api/hosts/$id/subscription
> POST /api/hosts/$id/content
>
> My opinion is that we go all-in and combine hosts. We are, in fact, a single project and community. There won't be name clashes because a PR to either foreman or katello with a clash would be NACKed.

No, the attributes of all the facets are combined together on the host json:

GET /api/hosts/$id would return:

{ 'id': 3,
'puppet_facet': {
'environment_id': 2
},
'content_facet': {
'content_view_id': 4
}
}

This is more referring to actions associated with a specific facet. For
puppet that would be: /api/hosts/$id/puppet/puppetrun, for content
that would be: /api/hosts/$id/content/packages as examples.

If the purpose is to go 'all-in' and combine hosts, why even use
facets? Just throw everything on the host object and 'hope' there are
no collisions. Are you going to monitor every plugin that anyone writes
to validate there are no conflicts? This isn't just about foreman and
katello, but also scap, discovery, remote execution, docker, ostree, and
any other plugin that people want to write. The whole purpose of
separating the model into facets is to provide for a separation of
concerns and reduce conflicts, why not extend that to the api?

-Justin

···

On 11/11/2015 08:20 AM, Tom McKay wrote: > ----- Original Message ----- >> On 11/10/2015 05:18 PM, David Davis wrote:

David

On Tue, Nov 10, 2015 at 4:21 PM, Tom McKay <thomasmckay@redhat.com >>> mailto:thomasmckay@redhat.com> wrote:

 ----- Original Message -----
 > Hey,
 >
 > Apologies for reviving this thread, I somehow missed it
 originally and this
 > issue has come up for me during the work on my PR [1] to move
 packages from
 > systems to hosts.
 >
 > I'm personally in favor of just adding the sub-resources
 directly to the base
 > resource object, without the split.  In other words:
 >
 > /host/:id/puppet-classes
 > /host/:id/packages
 >
 > vs
 >
 > /host/:id/puppet/classes
 > /host/:id/content/packages
 >
 > The main reason being that you cannot CRUD /host/:id/puppet or
 > /host/:id/content; puppet and content are not resources, they are an
 > arbitrary (and somewhat meaningless to our users) grouping of
 aspects (or
 > facets?).  I think that consumers of our APIs will be confused
 about the
 > superfluous /content or /puppet and this pattern is also
 contrary to every
 > other REST API I have seen.
 >
 > Thoughts?
 >
 > Cheers,
 > Walden
 >
 > [1] https://github.com/Katello/katello/pull/5575
 >
 >
 >

 I too would prefer not having sub-resources.

 First, I don't want to try to get the existing foreman APIs to
 change their structure. Katello influence on core foreman has
 never been smooth and the topic of the API has already been
 thrashed about over the past couple years. Putting the details
 directly onto the host API means foreman doesn't need to change
 and things can progress.

 Second, the reason for this host unification work is to allow the
 host object to be thought of as a single object. If API routes are
 going to be segregated off by topic (assuming my first point is
 proven to be incorrect) then it is just exposing implementation
 details to the user. For example, there are certainly going to be
 attributes that bleed between two facets and I'd rather see the
 PUT /hosts/$id be able to work with a single call versus multiple.

 --
 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.
–
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.

Tomas_Strachota · November 18, 2015, 9:54am

> I think it would be nice to separate the issue to two:
> 1. properties that are returned/modified
> 2. actions that are invoked by the user
>
> About properties I would like to see a unified approach:
> GET /api/hosts/$id
> will return:
> {
> "name": "my.host.com",
> "puppet_attributes":{
> "environment": "production"
> }
> "subscription_attributes": {
> "subs_prop1": "val1"
> }
> }
>
> As an option we can allow direct access point to the facet via:
> GET /api/hosts/$id/puppet
> will return:
> {
> "environment": "production"
> }
> But this is a shortcut, and I don't think it has much of importance…
>
> About the actions, I think it is more important to create obvious
> separation. I don't think the user is oblivious to the fact that the
> host has many facets that are managed by Foreman. When the user want to
> perform some action on the host, he knows pretty clearly what facet the
> action belongs to. Let's take as an example puppet run: I think for the
> user it would be very clear that he has to POST /hosts/:id/puppet/run.
> Another thought is that it is a pretty indicative way to show an error
> too. If the host doesn't have puppet, but the user tries to invoke
> /hosts/:id/puppet/run, the user should get 404: hosts/:id/puppet does
> not exist.
> This way we can enjoy both worlds: Unified view on a single host, but
> namespaced actions that become clearer.
>

I like this approach. I agree with Tom that facets are implementation
details and it should be transparent to users when they query for
information about hosts.

At the same time placing actions in the facet sub-route seems as logical
structure and can give more space for avoiding possible conflicts.

T.

···

On 11/11/2015 02:48 PM, sshtein@redhat.com wrote:

On Wednesday, November 11, 2015 at 3:20:43 PM UTC+2, Tom McKay wrote:

----- Original Message -----
 > On 11/10/2015 05:18 PM, David Davis wrote:
 > > I tend to like the unified/no subresources approach better as
it seems
 > > less cluttered and a lot simpler. However, my concern would be
what do
 > > we do about conflicts? Suppose Foreman implements a host action
(eg
 > > packages, puppet-classes, etc) that Katello is already
defining. If a
 > > conflict does arise and Katello has to use another route,
that’s going
 > > to be problematic in that Katello is suppose to maintain backwards
 > > compatibility in its API between releases. If we have
subresources I
 > > think a conflict would be less likely.
 >
 > I would also add that if a host can have different features/facets
 > enabled or disabled it would help the user match up which actions
 > correspond to which facet with a 'namespaced/subresource' approach.
 > Otherwise a user would have no idea which rest actions correspond
with
 > the 'puppet' facet if the puppet aspect is not enabled for a
particular
 > host.
 >
 > -Justin

As a consumer of a host, I don't think I should have to arbitrarily
know if a host has the puppet facet or not.

GET /api/hosts/$id/puppetclass_ids -> []
POST /api/hosts/$id/puppetclass_ids  <-- Creates a puppet facet if
one doesn't exist yet?

Or do I need to query the host itself to get a "these are your
facets" result?

GET /api/hosts/$id -> {facets: {puppet: false, salt: false, chef:
false, content: true, subscription: true}}

Even without puppet being true, might I not still have puppet content?

GET /api/hosts/$id/puppet_modules  <- Hypothetical route to return
puppet from host's lifecycle environment

You are asking me, the user, to know that although it's a single
host object it is really several objects (facets) in the tool. And
also to know what fields come from which facet, even if they are
conceptually related.

Would I have to
GET /api/hosts/$id/puppet
GET /api/hosts/$id/subscription
GET /api/hosts/$id/content
<combine results client side>
POST /api/hosts/$id/puppet
POST /api/hosts/$id/subscription
POST /api/hosts/$id/content

My opinion is that we go all-in and combine hosts. We are, in fact,
a single project and community. There won't be name clashes because
a PR to either foreman or katello with a clash would be NACKed.

 >
 > >
 > >
 > > David
 > >
 > > On Tue, Nov 10, 2015 at 4:21 PM, Tom McKay <thoma...@redhat.com >     <javascript:> >      > > <mailto:thoma...@redhat.com <javascript:>>> wrote:
 > >
 > >
 > >
 > >     ----- Original Message -----
 > >     > Hey,
 > >     >
 > >     > Apologies for reviving this thread, I somehow missed it
 > >     originally and this
 > >     > issue has come up for me during the work on my PR [1] to
move
 > >     packages from
 > >     > systems to hosts.
 > >     >
 > >     > I'm personally in favor of just adding the sub-resources
 > >     directly to the base
 > >     > resource object, without the split.  In other words:
 > >     >
 > >     > /host/:id/puppet-classes
 > >     > /host/:id/packages
 > >     >
 > >     > vs
 > >     >
 > >     > /host/:id/puppet/classes
 > >     > /host/:id/content/packages
 > >     >
 > >     > The main reason being that you cannot CRUD
/host/:id/puppet or
 > >     > /host/:id/content; puppet and content are not resources,
they are an
 > >     > arbitrary (and somewhat meaningless to our users)
grouping of
 > >     aspects (or
 > >     > facets?).  I think that consumers of our APIs will be
confused
 > >     about the
 > >     > superfluous /content or /puppet and this pattern is also
 > >     contrary to every
 > >     > other REST API I have seen.
 > >     >
 > >     > Thoughts?
 > >     >
 > >     > Cheers,
 > >     > Walden
 > >     >
 > >     > [1] https://github.com/Katello/katello/pull/5575
<https://github.com/Katello/katello/pull/5575>
 > >     >
 > >     >
 > >     >
 > >
 > >     I too would prefer not having sub-resources.
 > >
 > >     First, I don't want to try to get the existing foreman APIs to
 > >     change their structure. Katello influence on core foreman has
 > >     never been smooth and the topic of the API has already been
 > >     thrashed about over the past couple years. Putting the details
 > >     directly onto the host API means foreman doesn't need to
change
 > >     and things can progress.
 > >
 > >     Second, the reason for this host unification work is to
allow the
 > >     host object to be thought of as a single object. If API
routes are
 > >     going to be segregated off by topic (assuming my first
point is
 > >     proven to be incorrect) then it is just exposing
implementation
 > >     details to the user. For example, there are certainly going
to be
 > >     attributes that bleed between two facets and I'd rather see
the
 > >     PUT /hosts/$id be able to work with a single call versus
multiple.
 > >
 > >     --
 > >     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...@googlegroups.com <javascript:>
 > >     <mailto:foreman-dev%2Bunsubscribe@googlegroups.com
<javascript:>>.
 > >     For more options, visit https://groups.google.com/d/optout
<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...@googlegroups.com <javascript:>
 > > <mailto:foreman-dev+unsubscribe@googlegroups.com <javascript:>>.
 > > For more options, visit https://groups.google.com/d/optout
<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...@googlegroups.com <javascript:>.
 > For more options, visit https://groups.google.com/d/optout
<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.