[jboss-as7-dev] Configuration/management functionality AS/Fuse

[Andrig Miller]

I think we are generally in agreement here, in terms of the base/core runtime that everything layers on top of. 

I have more than just the two things you have below in the base/core, but that really because to have the management layer, you also have to have some basic networking and security components, and some other things to make it actually function. 

I'll leave the "how we actually layer additional capabilities that make up our platforms" to everyone else. 

If we can agreement on the base/core, at least conceptually, then we will be a very good place. Based on my own research into the existing modules, and how they are structured, there is some work that has to be done to refactor things (pull some things apart) to accomplish this, but in the end it doesn't appear to be rocket science. 

Andy 

----- Original Message -----

> From: "Thomas Diesler" <thomas.diesler at jboss.com>
> To: "Andrig Miller" <anmiller at redhat.com>
> Cc: "jboss-as7-dev at lists.jboss.org Development"
> <jboss-as7-dev at lists.jboss.org>, osgi-wrk-grp at redhat.com, "Brian
> Stansberry" <brian.stansberry at redhat.com>, "Guillaume Nodet"
> <gnodet at redhat.com>
> Sent: Monday, March 11, 2013 8:59:27 AM
> Subject: Re: [jboss-as7-dev] Configuration/management functionality
> AS/Fuse

> Hi Andy,

> I talked about this in Brno a couple of times - not sure whether you
> were in the room/bar though ;-)

> My idea would be the that the Core Runtime has

> * General unified Configuration/Management functionality
> * Logging functionality

> Today we wire stuff together by creating hard coded links between
> modules/components (in modules.xml). Hence tightly coupling stuff
> such that you cannot reason about A without taking B into
> consideration.

> A future model could be more declarative. Every component, subsystem,
> abstract feature, etc could declare its respective
> capabilities/requirements. Today we already have a Resource API that
> talks about generic caps/reqs and associates them to resources,
> which can be an abstract resources that combine other resources. All
> resources live together with their associated caps/reqs in a
> Repository , for which we also have an API and a RI. The missing
> piece is a Provisioning Service that you can give a set of
> requirements (i.e. the feature(s) you want to provision). The
> Provisioning Service would go to the Resolver (which we also have)
> to find a consistent solution that provides the wanted set of
> capabilities. The resolver takes capabilities that already exist in
> the runtime into account and ultimately provisions additional
> resources from the repository such that the wanted feature(s) become
> available. IMHO, this should not be a human decision - for a complex
> system it could quickly become impossible for a human to make the
> correct decisions such that the wiring is consistent.

> From the user perspective, the Core Runtime could have an SSH
> endpoint that you can connect to using your favourite SSH client
> (i.e. no proprietary client app). You could say

> > > add feature webservices,ejb3,configadmin
> 
> These would be abstract requirements that cause the webservice, ejb3,
> osgi subsystems (including their transitive set of dependencies) to
> get provisioned. The Resolver would know about the set of
> capabilities that are already available in the runtime and would
> provision only the missing delta from the repository. It would do a
> no-impact analysis first, i.e. try to find out if there is a
> consistent solution before anything gets provisioned which modifies
> the Runtime.

> The resulting wiring between the components would be persisted (like
> in modules.xml) such that on subsequent startups we get an identical
> wiring and no performance impact. Such highly pluggable system would
> be nice for developers that only want the subsystems that they
> really need, but would probably be not so applicable for layered
> products. However productisation people could use the same mechanism
> to define their product stack and be sure that for the given set of
> features they only have the necessary set of binaries in the
> distribution with a guaranteed accurate wiring between them.

> What is described above for runtime, could also happen at build time.
> The productisation folks would give the set of wanted product
> features to the build. The result of the build would again be a
> distribution that only contains the necessary set of binaries with a
> guaranteed accurate wiring between them.

> A side effect of this is that component, subsystem, abstract feature,
> etc can have an independent development lifecycle of each other and
> become more loosely coupled. An individual piece only needs to
> reason about its own capabilities and requirements. It is the job of
> a central, non-human authority (i.e. the Resolver) to bring
> everything together in a consistent way.

> In a nutshell: Product features would be defined as abstract
> resources with associated caps/reqs and live in a repository. A
> provisioning service connects the resolver with the repository and
> can provision additional features/resources to the runtime taking
> existing resources and their wiring into account. This can be done
> at build time and guarantees a small as possible and consistent
> distribution. The process is also highly agile and can react quickly
> to changing product requirements.

> If wanted I could talk lots about the details of this, but thats a
> little premature I guess.

> Good Luck in New Castle
> --thomas

> On Mar 8, 2013, at 11:33 PM, Andrig Miller < anmiller at redhat.com >
> wrote:

> > This is a great topic, but it might be a couple of weeks premature.
> 

> > During the FY'14 kickoff meetings in NewCastle, we will be
> > discussing
> > this topic, from the idea of having a core/base that all products,
> > including EAP would be layered on top of.
> 

> > I am responsible for presenting this basic idea, and have done some
> > work already on understanding what I think that core or base
> > infrastructure would look like.
> 

> > Having said that, my general idea is that the base or core
> > infrastructure would consist of the MSC/and domain components
> > (along
> > with others) that form the basis of a runtime and a management
> > layer, with one management and configuration API. Everything else
> > would layer on top of that, and share the same management layer
> > below.
> 

> > Andy
> 

> > ----- Original Message -----
> 

> > > From: "Thomas Diesler" < thomas.diesler at jboss.com >
> > 
> 
> > > To: "Brian Stansberry" < brian.stansberry at redhat.com >,
> > > "Guillaume
> > > Nodet" < gnodet at redhat.com >
> > 
> 
> > > Cc: " jboss-as7-dev at lists.jboss.org Development" <
> > > jboss-as7-dev at lists.jboss.org >, osgi-wrk-grp at redhat.com
> > 
> 
> > > Sent: Friday, March 8, 2013 9:21:33 AM
> > 
> 
> > > Subject: [jboss-as7-dev] Configuration/management functionality
> > > AS/Fuse
> > 
> 

> > > Hi Brian/Guillaume,
> > 
> 

> > > in the OSGi Working Group kick-off meeting I proposed a line of
> > > thought does goes like this:
> > 
> 

> > > * AS can be seen as an R5 compliant Core Framework that can be
> > > bootstrapped like any other compliant framework. We can take
> > > proper
> > > behaviour of the OSGi API layer for granted and can therefore
> > > safely
> > > assume that the Core Framework that Karaf currently runs on (i.e.
> > > Felix) can be replaced by AS.
> > 
> 
> > > * For long term consolidation of the two product lines (i.e. EAP
> > > &
> > > Fuse) there are two functional areas key: management and
> > > configuration
> > 
> 
> > > * There should be one way to configure the various subsystems
> > > that
> > > run on the platform
> > 
> 
> > > * There should be one API for managing the platform
> > 
> 
> > > * The consolidation effort could initially focus on these two
> > > areas
> > > and aim to elliminate functional overlap and conflicts
> > 
> 

> > > In parallel to the general requirement gathering I'd like to
> > > start
> > > a
> > > conversation about the respective management/configuration
> > > functionality in the two product lines and initially identify the
> > > overlap/conflicts. Perhaps we could start with the easier of the
> > > two
> > > (i.e. configuration) and hear from each other how this currently
> > > works.
> > 
> 

> > > * How are Fuse products configured?
> > 
> 
> > > * How does AS unified configuration work?
> > 
> 

> > > The goal would be to come up with a specific set of requirements
> > > for
> > > the target platform that accommodates the configuration needs for
> > > both product lines. We could then have a simmilar approach for
> > > the
> > > management layer.
> > 
> 

> > > What do you think?
> > 
> 

> > > cheers
> > 
> 
> > > --thomas
> > 
> 

> > > xxxxxxxxxxxxxxxxxxxxxxxxxxxx
> > 
> 
> > > Thomas Diesler
> > 
> 
> > > JBoss OSGi Lead
> > 
> 
> > > JBoss, a division of Red Hat
> > 
> 
> > > xxxxxxxxxxxxxxxxxxxxxxxxxxxx
> > 
> 

> > > _______________________________________________
> > 
> 
> > > jboss-as7-dev mailing list
> > 
> 
> > > jboss-as7-dev at lists.jboss.org
> > 
> 
> > > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
> > 
> 
> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
> Thomas Diesler
> JBoss OSGi Lead
> JBoss, a division of Red Hat
> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-as7-dev/attachments/20130311/c8386265/attachment.html