Supported Feature Checking Proposal

[Devan Goodwin]

Not much new here, just chatting with Dmitri today about how we can
have subscription-manager check if the server it's registered against
supports things like environments and package profiles. Proposal is to
use the same partial HATEOAS stuff we already implemented in
Candlepin:

curl -k -u testuser1:password https://localhost:8443/candlepin/

Returns something like:

[ {
  "rel" : "admin",
  "href" : "/admin"
}, {
  "rel" : "users",
  "href" : "/users"
}, {
  "rel" : "atom",
  "href" : "/atom"
}, {
  "rel" : "serials",
  "href" : "/serials"
}, {
  "rel" : "consumers",
  "href" : "/consumers"
}, {

...

Package profile support implies the use of a top level package
resource, which Katello already has, and Candlepin does not. Similar
for environments. In our case the JSON returned above would not have
packages or environments listed, and Katello would.

Dmitri is ok with this format we're using to return the links and is
going to ask about adding a backlog item to support the same response
type in Katello.

This is rather simple and HATEOASy, resource discovery as a way to
determine what features are supported. Seem ok?

Thanks,

Devan

[Bryan Kearney]

On 06/24/2011 11:08 AM, Devan Goodwin wrote:
> This is rather simple and HATEOASy, resource discovery as a way to
> determine what features are supported. Seem ok?
>
> Thanks,

So.. to be clear... this means that the api controllers would support a

/environments

and a

/packagesets

??

Does this mean that althouhg we want folks to access

/org/{org_id}/environemnts

we will always support a

/envrironments/{env_id} url?

-- bk

[Devan Goodwin]

On Fri, Jun 24, 2011 at 12:11 PM, Bryan Kearney  wrote:
> On 06/24/2011 11:08 AM, Devan Goodwin wrote:
> > This is rather simple and HATEOASy, resource discovery as a way to
> > determine what features are supported. Seem ok?
> >
> > Thanks,
>
> So.. to be clear... this means that the api controllers would support a
>
> /environments
>
> and a
>
> /packagesets

Just /packages hopefully as this is already in Katello, we think this
is the same resource we're talking about associating with a consumer
so hopefully a good indicator of the support we want.
> ??
>
> Does this mean that althouhg we want folks to access
>
> /org/{org_id}/environemnts
>
> we will always support a
>
> /envrironments/{env_id} url?

The plan we talked about for URLs awhile back was if you want the
sub-collection for an org, you go /org/id/environments, but if you
have an actual ID you go back to /environments. We're using this in
Candlepin and talking to Dmitri this should the case for Katello too.

With these in mind /environments and /packages seemed like a
consistent clean way to check.

Cheers,

Devan