[Hawkular-dev] inventory API: can I get a feed ID from a resource ID?

John Mazzitelli mazz at redhat.com
Mon Jul 20 09:37:36 EDT 2015


I'm not sure how the UI knows the feed ID to use. I'll defer to the UI guys how they do it. I wonder how they get the feed ID to use with the resource ID?

The agent is easy - I know my feed ID :) For the UI, I'm not sure how they know what the agent's feed ID is when talking about my agent's resources (versus the pinger's resources, let's say - or another agent).

----- Original Message -----
> The REST URLs always resembled what is now formalized in the "canonical path"
> of the entities.
> 
> If you accessed resource with ID "a", you never did that just by using that
> "a". You had to mention the tenantID (deduced from the auth info), the
> environmentID (part of the URL) and feedID (if the resource lived under a
> feed). That is precisely what the canonical path contains, too.
> 
> So from the user of the REST interface nothing really changed apart from the
> fact that 0.2.0.Alpha1 supports resource hierarchy (which is expressed as a
> URL path, too).
> 
> On Monday, July 20, 2015 09:16:23 John Mazzitelli wrote:
> > This is important to know from a UI perspective. Right now, I store the
> > resource ID under the tenant ID.
> > 
> > The UI (IIRC) only has the resource ID. From what you just said Lukas, that
> > doesn't seem like its unique enough.
> > 
> > This might be an issue with the UI.
> > 
> > ----- Original Message -----
> > 
> > > In Inventory 0.2.0.Alpha1 which I am about to release today if no
> > > breakage
> > > was
> > > discovered during my absence:
> > > 
> > > If you have the resource java object, which I think you have in agent,
> > > you
> > > simply do:
> > > 
> > > resourceObject.getPath().ids().getFeedId();
> > > 
> > > Long version:
> > > 
> > > All inventory entities now store a "canonical path" which is a path going
> > > down
> > > from tenant do the entity in question following the "contains"
> > > relationships.
> > > 
> > > The above call will take the resource object's path analyze it using the
> > > "ids()" call and will return the feed id, if the resource is contained
> > > within a feed or null, if the resource lives directly under an
> > > environment.
> > > 
> > > Also if you just store the resource ID, remember that that is only
> > > "locally
> > > unique" within your feed, so to reliably get the correct resource, you
> > > only
> > > can search for it within the feed:
> > > 
> > > inventory.tenants().getAll("asdf").environments().get("asf").feeds("myfeed
> > > ") .resources().get("resource-id");
> > > 
> > > If you also store the canonical path of the resource, you could do:
> > > 
> > > inventory.inspect(CanonicalPath.fromString("resource-path"),
> > > Resources.Single.class);
> > > 
> > > which would return to you the same access object as the above call.
> > > 
> > > So when you create your resource, you supply locally unique id, and can
> > > use
> > > the access object returned from the create method to get the newly
> > > created
> > > resource which will contain its full canonical path and all the other
> > > details.
> > > 
> > > On Friday, July 17, 2015 15:11:42 John Mazzitelli wrote:
> > > > To the inventory folks: is there an API that gives me a feed ID if all
> > > > I
> > > > know is a resource ID? If there is no API, can I get one? :)
> > > > 
> > > > We'll need a way to determine what feed is responsible for managing
> > > > what
> > > > parts of the inventory. So, given that clients like the UI will only
> > > > know
> > > > about things like resource ID, that's all they will be able to give the
> > > > kettle - but the server-side components will need to take that resource
> > > > ID
> > > > and get its associated feed ID so it can pass messages to the feed that
> > > > is
> > > > managing that resource. _______________________________________________
> > > > hawkular-dev mailing list
> > > > hawkular-dev at lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 
> 


More information about the hawkular-dev mailing list