<div dir="ltr">Ok, that way, we can just use '/sync' to sycn with inventory.<br><div class="gmail_quote"><div dir="ltr">On Fri, Jul 8, 2016 at 10:00 PM Thomas Segismont <<a href="mailto:tsegismo@redhat.com" target="_blank">tsegismo@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Austin,<br>
<br>
Not sure what you meant, but my opinion on the problem so far is that we<br>
should have a feed per Vert.x instance. Eventually (but that is beyond<br>
the scope of your project) we could find out when two Vert.x feeds are<br>
using the same clustered EventBus and then create a "logical" resource<br>
in inventory to represent it.<br>
<br>
Thomas<br>
<br>
Le 05/07/2016 à 01:53, Austin Kuo a écrit :<br>
> 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,<br>
> the feeds it contains should disappear as well.<br>
><br>
> Austin<br>
> Lukas Krejci <<a href="mailto:lkrejci@redhat.com" target="_blank">lkrejci@redhat.com</a> <mailto:<a href="mailto:lkrejci@redhat.com" target="_blank">lkrejci@redhat.com</a>>>於 2016年6<br>
> 月29日 週三，21:20寫道：<br>
><br>
> Btw. I've slightly updated the inventory organization description on the<br>
> hawkular site (<a href="http://www.hawkular.org/docs/components/inventory/" rel="noreferrer" target="_blank">http://www.hawkular.org/docs/components/inventory/</a><br>
> index.html#inventory-organization<br>
> <<a href="http://www.hawkular.org/docs/components/inventory/index.html#inventory-organization" rel="noreferrer" target="_blank">http://www.hawkular.org/docs/components/inventory/index.html#inventory-organization</a>>).<br>
> I hope it explains the structure and<br>
> intent of the entities in inventory in a slightly more<br>
> 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<br>
> look into<br>
> > >> this and will certainly come back with more questions.<br>
> > >><br>
> > >> With respect to the user creating resources question, the<br>
> difference<br>
> > >> between Vert.x and Wildfly is that the user creates resources<br>
> > >> grammatically. So in version 1 of the application, there might<br>
> be two<br>
> > >> HTTP servers as well as 7 event bus handlers, but only 1 http<br>
> 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<br>
> 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<br>
> not really<br>
> > > know who is talking to it - if a feed or if a user) - but<br>
> 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,<br>
> metric types<br>
> > > and they also declare resources and metrics of those types. Feed<br>
> 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<br>
> 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<br>
> 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<br>
> exactly the<br>
> same configuration definitions, they are considered identical. If<br>
> you know 1<br>
> resource type, you can find all the identical ones using the<br>
> following REST<br>
> API (since 0.17.0.Final, the format of the URLs is thoroughly<br>
> 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"<br>
> resource types<br>
> under the tenant, that would have the same id and structure as the<br>
> types that<br>
> the feeds declare. If then you want to for example find all<br>
> 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<br>
> defined by<br>
> those types.<br>
><br>
> > > Hence the /sync endpoint applies to a feed nicely - since it is<br>
> in charge,<br>
> > > it merely declares what is the view it has currently of the<br>
> "world" it<br>
> > > sees and inventory will make sure it has the same picture -<br>
> under that<br>
> > > feed.<br>
> > ><br>
> > > Now if you have an application that spans multiple vms/machines<br>
> and is<br>
> > > composed of multiple processes, there is no such clear<br>
> distinction of<br>
> > > "ownership".<br>
> ><br>
> > Good point, Vert.x applications are often distributed and<br>
> 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<br>
> 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<br>
> creates<br>
> > > "logical" resources in the environment (i.e. "My App" resource<br>
> in staging<br>
> > > env is composed of a load balancer managed by this feed, mongodb<br>
> 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 -<br>
> 1 created<br>
> > > using the "contains" relationship, which expresses existential<br>
> ownership -<br>
> > > i.e. a feed contains its resources and if a feed disappears, so<br>
> do the<br>
> > > resources, because no one else can report on them. The entities<br>
> 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<br>
> through the<br>
> > Ruby client?<br>
> ><br>
><br>
> yes<br>
><br>
> > > contains relationship form a tree - no loops or diamonds in it<br>
> (this is<br>
> > > enforced by inventory). But there can also be a hierarchy<br>
> created using an<br>
> > > "isParentOf" relationship (which represents "logical" ownership).<br>
> > > Resources<br>
> > > bound by "isParentOf" can form an acyclic graph - i.e. 1<br>
> resource can have<br>
> > > multiple parents as well as many children (isParentOf is<br>
> applicable only<br>
> > > to<br>
> > > resources, not other types of entities).<br>
> > ><br>
> > > The hierarchies formed by "contains" and "isParentOf" are<br>
> independent. So<br>
> > > you can create a resource "My App" in the staging environment<br>
> and declare<br>
> > > it a parent (using "isParentOf") of the resources declared by<br>
> 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<br>
> logical app<br>
> > resource as parent.<br>
> ><br>
><br>
> Exactly.<br>
><br>
> > > That is the envisaged workflow for "apps". Now the downside to<br>
> 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<br>
> 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<br>
> a feed<br>
> > > doesn't "see" a resource, then it really is just gone, because<br>
> the feed is<br>
> > > solely responsible for reporting on it).<br>
> ><br>
> > What happens to the resources exactly? Are they marked as gone or<br>
> simply<br>
> > deleted?<br>
><br>
> Right now they are deleted. That is of course not optimal and<br>
> versioning is in<br>
> the pipeline right after the port of inventory to Tinkerpop3.<br>
> 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<br>
> 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<br>
> a JMS<br>
> > queue is gone, are alert definitions on queue depth removed as<br>
> 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"<br>
> but I'm not<br>
> > > sure if having a feed for vertx is the right thing to do. On the<br>
> other<br>
> > > hand I very well may not be seeing some obvious problems of the<br>
> above or<br>
> > > parallels that make the 2 approaches really the same because the<br>
> above<br>
> > > model is just ingrained in my brain after so many hours thinking<br>
> 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<br>
> it's not<br>
> > >> much different than the Hawkular Agent.<br>
> > ><br>
> > > A feed would only be appropriate if vertx app never reported on<br>
> something<br>
> > > that would also be reported by other agents. I.e. if a part of a<br>
> vertx<br>
> > > application is also reported on by a wfly agent, because that<br>
> 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<br>
> 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<br>
> Agent.<br>
> ><br>
> > >> Maybe the wording around user creating resources was confusing?<br>
> Did you<br>
> > >> thought he would do so from application code? In this case, the<br>
> answer<br>
> > >> is no.<br>
> > ><br>
> > > Yeah, we should probably get together and discuss what your<br>
> 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<br>
> <<a href="mailto:lkrejci@redhat.com" target="_blank">lkrejci@redhat.com</a> <mailto:<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> <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<br>
> is used to<br>
> > >>> synchronize the "world view" of feeds (feed being<br>
> something that<br>
> > >>> pushes data<br>
> > >>> into inventory).<br>
> > >>><br>
> > >>> You said though that a "user creates" the resources, so I<br>
> am not<br>
> > >>> sure if /sync<br>
> > >>> would be applicable to your scenario. Would you please<br>
> elaborate<br>
> > >>> more on where<br>
> > >>> in the inventory hierarchy you create your resources and<br>
> how? I.e.<br>
> > >>> are you<br>
> > >>> using some sort of feed akin to Hawkular's Wildfly Agent<br>
> 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<br>
> server.<br>
> > >>> > Here’s the example scenario:<br>
> > >>> > Consider the following problem. A user creates version 1<br>
> of the<br>
> > >>><br>
> > >>> app with<br>
> > >>><br>
> > >>> > two http servers, one listening on port 8080, the other<br>
> on port<br>
> > >>><br>
> > >>> 8181. In<br>
> > >>><br>
> > >>> > version 2, the http server listening on port 8181 is no<br>
> longer<br>
> > >>> > needed.<br>
> > >>> > When the old version is stopped and the new version<br>
> started, there<br>
> > >>><br>
> > >>> will be<br>
> > >>><br>
> > >>> > just one http server listening. The application is not<br>
> aware of<br>
> > >>> > the<br>
> > >>> > previous state. What should we do so that the second<br>
> 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><br>
> <mailto:<a href="mailto:hawkular-dev@lists.jboss.org" target="_blank">hawkular-dev@lists.jboss.org</a>><br>
> <mailto:<a href="mailto:hawkular-dev@lists.jboss.org" target="_blank">hawkular-dev@lists.jboss.org</a><br>
> <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> <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>
> --<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>
><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>
Thomas Segismont<br>
JBoss ON Engineering Team<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></div>