[Hawkular-dev] Identification of WildFly in container in a Kube/Openshift env

[John Mazzitelli]

I would say first we should not expect people to be happy to have install a _second_ subsystem extension to just to support Hawkular (having a separate feature pack, installer, separate <subsystem> in standalone.xml, etc. etc). But we could add more extension *services* or DUPs (see below) to the Hawkular WildFly Agent subsystem itself and it just comes with the agent with no additional installation or configs necessary.

Also, this feature of building a feed ID based on content within the app server is going to have drawbacks when you consider it won't work if the app server's deployments could ever change (add deployments, remove deployments, or even just patching existing deployments if the version string is part of the deployment filename [foobar-1.0.war -> foobar-2.0.war]) So this feature would be very restrictive in who should be using it and people should be very aware of it in case they turn that feature on when they shouldn't (because the consequences would be bad - the agent's feed ID would change underneath of it simply when a deployment changed).

That said, what might be possible (given the restrictions noted above), if we do want to support such a thing, we could allow a new pre-defined value for <storage-adapter>'s "feed-id" attribute. We already have one - "autogenerate". We could have something like "autogenerate-based-on-deployments". If the agent sees this, it could in theory add a DUP (DeploymentUnitProcessor) to the series of DUPs in the app server. This DUP of ours would pass through the deployments, but before it does it looks at the deployment name and keeps a running sha1 hash, building up the final hash when all deployments are passed through, put it somewhere the agent can access, and that will be the feed ID. (note if the "real" deployer that will handle that deployment actually rejects the deployment, we might have a problem because we'll have hashed on something that isn't really deployed - I don't know if our DUP can see when a deployment is rejected down the chain).

We already do this kind of thing in RHQ. We add a DUP [1] and in the DUP (in RHQ anyway) we look at the name of the deployment and if it isn't rhq.war, the deployment is rejected [2]. For Hawkular, we just let it pass through and deploy but we'd create the hash based on the name.

[1] https://github.com/rhq-project/rhq/blob/master/modules/enterprise/server/startup-subsystem/src/main/java/org/rhq/enterprise/startup/StartupSubsystemAdd.java#L65-L71

[2] https://github.com/rhq-project/rhq/blob/master/modules/enterprise/server/startup-subsystem/src/main/java/org/rhq/enterprise/startup/StartupCrippledDeploymentProcessor.java#L15-L31

----- Original Message -----
> On 27.07.2016 19:06, Juraci Paixão Kröhling wrote:
> > On 27.07.2016 18:51, John Mazzitelli wrote:
> >>> - feed-id: sha1sum(sha1sum(foobar.war) + sha1sum(foobar-ds.xml))
> >>> result: a4f36be49f641967e51e2707c1fe6d0a29c2f682
> >>
> >> Calculating the feed ID based on discovered resources is going to be very
> >> difficult if not impossible with the current implementation - the agent
> >> needs the feed ID upfront during startup before it even runs discovery
> >> (i.e. before it even knows about any resources - let along child
> >> resources like deployments) - it requires the feed ID internally to start
> >> many components, it can't talk to hawkular-inventory without it, and it
> >> needs the feed ID to connect to the hawkular cmdgw server.
> >
> > I considered this, but I thought it wouldn't be a problem to implement a
> > separate Wildfly extension that would calculate this during the boot and
> > put the resulting value in a system property for later use by the agent
> > itself. Would that work?
> 
> By the way: I don't think this extension needs to wait for the deployers
> either: all it would need to do is to get a VirtualJarInputStream for
> each of the deployments, and calculate the sha1sum based on that.
> 
> - Juca.
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>