RFC: to show Credential Definitions with Provider Type or not

Petr Blaho pblaho at redhat.com
Tue Nov 13 15:06:29 UTC 2012


On Tue, Oct 16, 2012 at 11:24:43PM -0700, Richard Su wrote:
> On 10/16/2012 01:20 PM, Jason Guiditta wrote:
> >On 09/10/12 14:31 -0400, Scott Seago wrote:
> >>On 10/09/2012 12:31 PM, Petr Blaho wrote:
> >>>Hi,
> >>>
> >>>I am working on show action for Provider Type API and I am not sure if
> >>>I
> >>>should include Credential Definitions in XML representation of Provider
> >>>Type resource at all (probably bad idea), use only ids and hrefs or if
> >>>hsould I include the whole subresource there.
> >>>
> >>>The similar question goes for create action. Should the user
> >>>be able to create new Credential Definitions from within Provider Type
> >>>data XML provided to create action? And the same for update action.
> >>>
> >>>Or should be Credential Definition resource of its own?
> >>>
> >>>Looking for your input.
> >>>
> >>>--
> >>>
> >>>With Regards
> >>>Petr Blaho
> >>
> >>I'm thinking that it really belongs to the provider type, so I'm not
> >>sure we want it as a separate subresource. It's really just a modeling
> >>convenience that the CredentialDefinition is a separate object, since
> >>the number is variable, etc. Part of the definition of a provider type
> >>is the list of attributes for provider account credentials.
> >>
> >>Scott
> >>
> >
> >I am on the fence here.  I agree that a Credential Definition is meant
> >to be used with a Provider Type.  But is it true that the Credential Def
> >would never have a need to be used by itself?  That I am less sure of.
> >I think allowing a credential definition to be created when creating a
> >provider type is absolutely valid (ie, nested objects POSTed to
> >provider_type).  However, perhaps a user wants to see how many
> >credential definitions there are, or just look at (and perhaps update)
> >some of them.  Say I retrieve a list from
> >provider_types/1/credential_definitions.  This list shows me I have 2
> >different defs for one of my provider types.  I then want to go and
> >look at them directly, and then perhaps delete the duplicate (I know,
> >we have model validations to prevent this, it is just an example).
> >The point is, I actually want to go to credential_definitions/1, and
> >then PUT an update to same, rather than having that extra layer of
> >going through the provider_type.
> >
> >I'll note the additional question of 'how do I figure out what kinds
> >of credentials a given provider type needs' remains a bit ambiguous in
> >my mind, but I think that is a separate problem.
> >
> >Lastly, to answer the other part of the question, I think we have been
> >shooting for generally following the 'shallow resource' approach,
> >which would mean you include only the link to the proper uri so the
> >client can go and get the given credential defs they need.  That said,
> >we have some places where we allow the client to specify the want the
> >full resource, which I personally think is kind of a nice option to
> >provide (with a shallow default) in places like this, where the client
> >is likely to have to make a bunch of subsequent requests to look at
> >the details.
> >
> >-j
>
> Having credential_definitions implemented as a full resource would
> add some flexibility to updates.
>
> Which would be easiest to implement? (1) Having the credential
> definitions defined as part of the provider type definition? And not expose
>  them as a separate resource at all. or (2) Implement the definitions
> as a full resource.
>
> I can see a case for having both. Personally I would go with the easier
> option
> for now. We have other endpoints to implement that are of higher strategic
> priority. Once we have those done, we can circle back and implement the
> option we skipped.
>
>


OK,

I will follow route for shallow resources when reading Provider Type -
so it means that I will implement Credential Definition as resource too.
This looks simple way even if it is more code.

Next I can parse params to make it work
with embedded Credential Definition in Provider Type XML.

--
Petr Blaho, pblaho at redhat.com
Software Engineer, CloudForms



More information about the aeolus-devel mailing list