why "isParentOf" is more suitable than "contains" in vertx as Thomas said? <br><br>If it is "contains", it also makes sense to me since if "MyApp" is gone, the feeds it contains should disappear as well. <br><br>Austin<br><div class="gmail_quote"><div dir="ltr">Lukas Krejci <<a href="mailto:lkrejci@redhat.com">lkrejci@redhat.com</a>>於 2016年6月29日 週三，21:20寫道：<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Btw. I've slightly updated the inventory organization description on the<br>
hawkular site (<a href="http://www.hawkular.org/docs/components/inventory/index.html#inventory-organization" rel="noreferrer" target="_blank">http://www.hawkular.org/docs/components/inventory/<br>
index.html#inventory-organization</a>). I hope it explains the structure and<br>
intent of the entities in inventory in a slightly more comprehensible manner.<br>
<br>
My answers are inline below...<br>
<br>
On středa 29. června 2016 14:39:27 CEST Thomas Segismont wrote:<br>
> Thank you very much for the thorough reply Lukas. A few<br>
> questions/comments inline.<br>
><br>
> Le 23/06/2016 à 15:59, Lukas Krejci a écrit :<br>
> > On Thursday, June 23, 2016 10:27:12 AM Thomas Segismont wrote:<br>
> >> Hey Lukas,<br>
> >><br>
> >> Thank you for pointing us in the sync endpoint. Austin will look into<br>
> >> this and will certainly come back with more questions.<br>
> >><br>
> >> With respect to the user creating resources question, the difference<br>
> >> between Vert.x and Wildfly is that the user creates resources<br>
> >> grammatically. So in version 1 of the application, there might be two<br>
> >> HTTP servers as well as 7 event bus handlers, but only 1 http server in<br>
> >> version 2. And a named worker pool in version 3.<br>
> >><br>
> >> In the end, I believe it doesn't matter if it's container which creates<br>
> >> resources or if it's the user himself. Does it?<br>
> ><br>
> > It does not really (inventory has just a single API, so it does not really<br>
> > know who is talking to it - if a feed or if a user) - but resources inside<br>
> > and outside feeds have slightly different semantics.<br>
> ><br>
> > Right now the logic is this:<br>
> ><br>
> > Feeds are "agents" that don't care about anything else but their own<br>
> > little<br>
> > "world". That's why they can create their own resource types, metric types<br>
> > and they also declare resources and metrics of those types. Feed does not<br>
> > need to look "outside" of its own data and is in full charge of it.<br>
><br>
> Does that mean that creating a feed is the only way to create<br>
> resource/metric types?<br>
<br>
No, you can also create resource types and metric types directly under the<br>
tenant.<br>
<br>
> I suppose the benefit of creating resource types is that then you can<br>
> search for different resources of the same type easily.<br>
><br>
> And if feeds create resource types, how do you know that resource types<br>
> created by the Hawkular Agent feed running on server A are the same as<br>
> those created by another agent running on server B?<br>
><br>
<br>
Inventory automatically computes "identity hashes" of resource types and<br>
metric types - if 2 resource types in 2 feeds have the same ID and exactly the<br>
same configuration definitions, they are considered identical. If you know 1<br>
resource type, you can find all the identical ones using the following REST<br>
API (since 0.17.0.Final, the format of the URLs is thoroughly explained here:<br>
<a href="http://www.hawkular.org/docs/rest/rest-inventory.html#_api_endpoints" rel="noreferrer" target="_blank">http://www.hawkular.org/docs/rest/rest-inventory.html#_api_endpoints</a>):<br>
<br>
/hawkular/inventory/traversal/f;feedId/rt;resourceTypeId/identical<br>
<br>
If for example some resource types should be known up-front and "shared"<br>
across all feeds, some kind of "gluecode" could create "global" resource types<br>
under the tenant, that would have the same id and structure as the types that<br>
the feeds declare. If then you want to for example find all resources of given<br>
type, you can:<br>
<br>
/hawkular/inventory/traversal/rt;myType/identical/rl;defines/type=resource<br>
<br>
I.e. for all types identical to the global one, find all resources defined by<br>
those types.<br>
<br>
> > Hence the /sync endpoint applies to a feed nicely - since it is in charge,<br>
> > it merely declares what is the view it has currently of the "world" it<br>
> > sees and inventory will make sure it has the same picture - under that<br>
> > feed.<br>
> ><br>
> > Now if you have an application that spans multiple vms/machines and is<br>
> > composed of multiple processes, there is no such clear distinction of<br>
> > "ownership".<br>
><br>
> Good point, Vert.x applications are often distributed and communicating<br>
> over the EventBus.<br>
><br>
> > While indeed a "real" user can just act like a feed, the envisioned<br>
> > workflow is that the user operates directly in environments and at the<br>
> > top level. I.e. a user assigns feeds to environments (i.e. this feed<br>
> > reports on my server in staging environment, etc) and the user creates<br>
> > "logical" resources in the environment (i.e. "My App" resource in staging<br>
> > env is composed of a load balancer managed by this feed, mongodb managed<br>
> > by another feed there and clustered wflys there, there and there).<br>
> ><br>
> > To model this, inventory supports 2 kinds of tree hierarchies - 1 created<br>
> > using the "contains" relationship, which expresses existential ownership -<br>
> > i.e. a feed contains its resources and if a feed disappears, so do the<br>
> > resources, because no one else can report on them. The entities bound by<br>
> > the<br>
> How does a feed "disappear"? That would be by deleting it through the<br>
> REST API, correct? Something the ManageIQ provider would do through the<br>
> Ruby client?<br>
><br>
<br>
yes<br>
<br>
> > contains relationship form a tree - no loops or diamonds in it (this is<br>
> > enforced by inventory). But there can also be a hierarchy created using an<br>
> > "isParentOf" relationship (which represents "logical" ownership).<br>
> > Resources<br>
> > bound by "isParentOf" can form an acyclic graph - i.e. 1 resource can have<br>
> > multiple parents as well as many children (isParentOf is applicable only<br>
> > to<br>
> > resources, not other types of entities).<br>
> ><br>
> > The hierarchies formed by "contains" and "isParentOf" are independent. So<br>
> > you can create a resource "My App" in the staging environment and declare<br>
> > it a parent (using "isParentOf") of the resources declared by feeds that<br>
> > manage the machines where the constituent servers live.<br>
><br>
> Interesting, that may be the way to model a Vert.x app deployed on two<br>
> machines. Each process would have its own feed reporting discovered<br>
> resources (http servers, event bus handlers, ... etc), and a logical app<br>
> resource as parent.<br>
><br>
<br>
Exactly.<br>
<br>
> > That is the envisaged workflow for "apps". Now the downside to that is<br>
> > that<br>
> > (currently) there is no "sync" for that. The reason is that the<br>
> > application<br>
> > really is a logical concept and the underlying servers can be repurposed<br>
> > to<br>
> > serve different applications (so if app stops using it, it shouldn't<br>
> > really<br>
> > disappear from inventory, as is the case with /sync - because if a feed<br>
> > doesn't "see" a resource, then it really is just gone, because the feed is<br>
> > solely responsible for reporting on it).<br>
><br>
> What happens to the resources exactly? Are they marked as gone or simply<br>
> deleted?<br>
<br>
Right now they are deleted. That is of course not optimal and versioning is in<br>
the pipeline right after the port of inventory to Tinkerpop3. Basically all<br>
the entities and relationships will get "from" and "to" timestamps.<br>
Implicitly, you'd look at the "present", but you'd be able to look at how<br>
things looked in the past by specifying a different "now" in your query.<br>
<br>
> Do you know how dependent services are updated? For example, when a JMS<br>
> queue is gone, are alert definitions on queue depth removed as well? How<br>
> does that happen?<br>
><br>
<br>
Inventory sends events on the bus about every C/U/D of every entity or<br>
relationship, so other components can react on that.<br>
<br>
> > We can think about how to somehow help clients with "App sync" but I'm not<br>
> > sure if having a feed for vertx is the right thing to do. On the other<br>
> > hand I very well may not be seeing some obvious problems of the above or<br>
> > parallels that make the 2 approaches really the same because the above<br>
> > model is just ingrained in my brain after so many hours thinking about it<br>
> > ;)<br>
> ><br>
> >> As for the feed question, the Vert.x feed will be the Metrics SPI<br>
> >> implementation (vertx-hawkular-metrics project). Again I guess it's not<br>
> >> much different than the Hawkular Agent.<br>
> ><br>
> > A feed would only be appropriate if vertx app never reported on something<br>
> > that would also be reported by other agents. I.e. if a part of a vertx<br>
> > application is also reported on by a wfly agent, because that part is<br>
> > running in a wfly server managed by us, then that will not work - 1<br>
> > resource cannot be "contained" in 2 different feeds (not just API wise,<br>
> > but logically, too).<br>
> I'm not too worried about this use case. First the vast majority of<br>
> Vert.x applications I know about are not embedded. Secondly the Vert.x<br>
> feed would not report resources already reported by the Hawkular Agent.<br>
><br>
> >> Maybe the wording around user creating resources was confusing? Did you<br>
> >> thought he would do so from application code? In this case, the answer<br>
> >> is no.<br>
> ><br>
> > Yeah, we should probably get together and discuss what your plans are to<br>
> > get on the same page with everything.<br>
><br>
> I believe that presenting to you (and to whoever is interested) the<br>
> conclusions of investigations would be beneficial indeed.<br>
><br>
<br>
+1<br>
<br>
> >> Regards,<br>
> >> Thomas<br>
> >><br>
> >> Le 23/06/2016 à 10:01, Austin Kuo a écrit :<br>
> >>> Yes, I’m gonna build the inventory for vertx applications.<br>
> >>> So I have to create a feed for it.<br>
> >>><br>
> >>> Thanks!<br>
> >>><br>
> >>> On Tue, Jun 21, 2016 at 7:55 PM Lukas Krejci <<a href="mailto:lkrejci@redhat.com" target="_blank">lkrejci@redhat.com</a><br>
> >>><br>
> >>> <mailto:<a href="mailto:lkrejci@redhat.com" target="_blank">lkrejci@redhat.com</a>>> wrote:<br>
> >>> Hi Austin,<br>
> >>><br>
> >>> Inventory offers a /hawkular/inventory/sync endpoint that is used to<br>
> >>> synchronize the "world view" of feeds (feed being something that<br>
> >>> pushes data<br>
> >>> into inventory).<br>
> >>><br>
> >>> You said though that a "user creates" the resources, so I am not<br>
> >>> sure if /sync<br>
> >>> would be applicable to your scenario. Would you please elaborate<br>
> >>> more on where<br>
> >>> in the inventory hierarchy you create your resources and how? I.e.<br>
> >>> are you<br>
> >>> using some sort of feed akin to Hawkular's Wildfly Agent or are you<br>
> >>> just<br>
> >>> creating your resources "manually" under environments?<br>
> >>><br>
> >>> On Tuesday, June 21, 2016 02:20:33 AM Austin Kuo wrote:<br>
> >>> > Hi all,<br>
> >>> ><br>
> >>> > I’m currently investigating how to sync with inventory server.<br>
> >>> > Here’s the example scenario:<br>
> >>> > Consider the following problem. A user creates version 1 of the<br>
> >>><br>
> >>> app with<br>
> >>><br>
> >>> > two http servers, one listening on port 8080, the other on port<br>
> >>><br>
> >>> 8181. In<br>
> >>><br>
> >>> > version 2, the http server listening on port 8181 is no longer<br>
> >>> > needed.<br>
> >>> > When the old version is stopped and the new version started, there<br>
> >>><br>
> >>> will be<br>
> >>><br>
> >>> > just one http server listening. The application is not aware of<br>
> >>> > the<br>
> >>> > previous state. What should we do so that the second http server<br>
> >>><br>
> >>> is removed<br>
> >>><br>
> >>> > from Inventory?<br>
> >>> ><br>
> >>> > Thanks in advance.<br>
> >>><br>
> >>> --<br>
> >>> Lukas Krejci<br>
> >>><br>
> >>> _______________________________________________<br>
> >>> hawkular-dev mailing list<br>
> >>> <a href="mailto:hawkular-dev@lists.jboss.org" target="_blank">hawkular-dev@lists.jboss.org</a> <mailto:<a href="mailto:hawkular-dev@lists.jboss.org" target="_blank">hawkular-dev@lists.jboss.org</a>><br>
> >>> <a href="https://lists.jboss.org/mailman/listinfo/hawkular-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/hawkular-dev</a><br>
> >>><br>
> >>> _______________________________________________<br>
> >>> hawkular-dev mailing list<br>
> >>> <a href="mailto:hawkular-dev@lists.jboss.org" target="_blank">hawkular-dev@lists.jboss.org</a><br>
> >>> <a href="https://lists.jboss.org/mailman/listinfo/hawkular-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/hawkular-dev</a><br>
<br>
<br>
--<br>
Lukas Krejci<br>
<br>
_______________________________________________<br>
hawkular-dev mailing list<br>
<a href="mailto:hawkular-dev@lists.jboss.org" target="_blank">hawkular-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/hawkular-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/hawkular-dev</a><br>
</blockquote></div>