yeah thanks for this :)<br><div class="gmail_quote"><div dir="ltr">Lukas Krejci <<a href="mailto:lkrejci@redhat.com">lkrejci@redhat.com</a>>於 2016年6月23日 週四，21:59寫道：<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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>
<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 and<br>
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 little<br>
"world". That's why they can create their own resource types, metric types and<br>
they also declare resources and metrics of those types. Feed does not need to<br>
look "outside" of its own data and is in full charge of it.<br>
<br>
Hence the /sync endpoint applies to a feed nicely - since it is in charge, it<br>
merely declares what is the view it has currently of the "world" it sees and<br>
inventory will make sure it has the same picture - under that 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>
While indeed a "real" user can just act like a feed, the envisioned workflow<br>
is that the user operates directly in environments and at the top level. I.e.<br>
a user assigns feeds to environments (i.e. this feed reports on my server in<br>
staging environment, etc) and the user creates "logical" resources in the<br>
environment (i.e. "My App" resource in staging env is composed of a load<br>
balancer managed by this feed, mongodb managed by another feed there and<br>
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 the<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). 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 to<br>
resources, not other types of entities).<br>
<br>
The hierarchies formed by "contains" and "isParentOf" are independent. So you<br>
can create a resource "My App" in the staging environment and declare it a<br>
parent (using "isParentOf") of the resources declared by feeds that manage the<br>
machines where the constituent servers live.<br>
<br>
That is the envisaged workflow for "apps". Now the downside to that is that<br>
(currently) there is no "sync" for that. The reason is that the application<br>
really is a logical concept and the underlying servers can be repurposed to<br>
serve different applications (so if app stops using it, it shouldn't 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>
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 hand I<br>
very well may not be seeing some obvious problems of the above or parallels<br>
that make the 2 approaches really the same because the above model is just<br>
ingrained in my brain after so many hours thinking about it ;)<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>
<br>
A feed would only be appropriate if vertx app never reported on something that<br>
would also be reported by other agents. I.e. if a part of a vertx application<br>
is also reported on by a wfly agent, because that part is running in a wfly<br>
server managed by us, then that will not work - 1 resource cannot be<br>
"contained" in 2 different feeds (not just API wise, but logically, too).<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>
<br>
Yeah, we should probably get together and discuss what your plans are to get<br>
on the same page with everything.<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 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>
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>