On Tue, 2013-04-02 at 10:41 +0200, Michal Fojtik wrote: > On 04/02/2013 02:26 AM, David Lutterkort wrote: > > On Thu, 2013-03-28 at 12:19 +1100, Koper, Dies wrote: > >> A bit of background on this patch: > >> It contains my latest work on implementing cimi systems and system > >> templates for mock and fgcp. > >> It is not complete and contains some debugging statements. Its main > >> purpose is to show you what I have and what issues I'm seeing. > >> > >> It applies to master (fcffad13e66175152cf8a43d615b79727902b5ee) and > >> requires "[PATCH] CIMI schema: tolerate nil hash_map attributes" to > >> solve a nil error for system templates with fgcp. > >> > >> Issues I'm having: > >> > >> (1) > >> With mock, even unsupported subcollections are shown when retrieving > >> systems. With fgcp they are also shown, and their href urls are broken: > > > > This is a shortcoming of how we populate models right now - there's no > > way to suppress collections that the driver doesn't support. In fact, > > the code goes through great length to make sure we generate the href for > > empty collections (since that href is needed to add the first element to > > an empty collection) > > > > The easiest way to 'fix' this for now is to comment those unsupported > > collections out in system.rb. > > > > A better fix is to add a mechanism similar to what we do for $select to > > models; call that the 'exclude' mechanism. The various generate_xxx > > methods should set the that exclude parameter based on collections that > > are declared in Rabbit, but not available (Rabbit knows that, Michal: > > how do we get that info out of Rabbit ?) > > How about this? > > module CIMI::Helper > > def supported_collections > CIMI::Service::CloudEntryPoint.create(self).entities > end > > end > > All 'Base' classes are in fact 'Sinatra::Base' and you can use all > defined Sinatra helpers in the Rabbit operation control block. > > Having this, you can do then following in all Service models: > > context.supported_collections.include? Collection
I don't think this is quite right - what I am looking for is for an easy way to determine which of the subcollections of, for example, System are supported by the current driver - for example, whether System.credentials should be populated or not. Rabbit knows that because of the various with_capability statements on operations for each subcollection. When the service object (or the driver, in the case of systems) sets up a model object, we'd like to completely omit System.credentials if the driver doesn't support it. If I can get my hands on which collections are supported according to Rabbit, it would be easy enough to write some code to omit unsupported collections. David
