On 11/27/2013 02:03 PM, Adrian Otto wrote:
Jay,
On Nov 27, 2013, at 10:36 AM, Jay Pipes <[email protected]> wrote:
On 11/27/2013 06:23 AM, Tom Deckers (tdeckers) wrote:
I understand the an Assembly can be a larger group of
components. However, those together exist to provide a capability
which we want to capture in some catalog so the capability
becomes discoverable. I'm not sure how the 'listing' mechanism
works out in practice. If this can be used in an enterprise
ecosystem to discover services then that's fine. We should
capture a work item flesh out discoverability of both
Applications and Assemblies. I make that distinction because
both scenarios should be provided. As a service consumer, I
should be able to look at the 'Applications' listed in the
Openstack environment and provision them. In that case, we
should also support flavors of the service. Depending on the
consumer-provider relationship, we might want to provide
different configuratons of the same Application. (e.g.
gold-silver-bronze tiering). I believe this is covered by the
'listing' you mentioned. Once deployed, there should also be a
mechanism to discover the deployed assemblies. One example of
such deployed Assembly is a persistence service that can in its
turn be used as a Service in another Assembly. The specific
details of the capability provided by the Assembly needs to be
discoverable in order to allow successful auto-wiring (I've seen
a comment about this elsewhere in the project - I believe in
last meeting).
Another thought around the naming of "Assembly"... there's no
reason why the API cannot just ditch the entire notion of an
assembly, and just use "Component" in a self-referential way.
In other words, an Application (or whatever is agree on for that
resource name) contains one or more Components. Components may
further be composed of one or more (sub)Components, which
themselves may be composed of further (sub)Components.
That way you keep the notion of a Component as generic and
encompassing as possible and allow for an unlimited generic
hierarchy of Component resources to comprise an Application.
As currently proposed, an Assembly (a top level grouping of
Components) requires only one Component, but may contain many. The
question is whether we should even have an Assembly. I admit that
Assembly is a new term, and therefore requires definition,
explanation, and examples. However, I think eliminating it and just
using Components is getting a bit too abstract, and requires a bit
too much explanation.
I consider this subject analogous to the fundamentals concepts of
Chemistry. Imagine trying to describe a molecule by only using the
concept of an atom. Each atom can be different, and have more or less
electrons etc. But if we did not have the concept of a molecule (a
top level grouping of atoms), and tried to explain them as atoms
contained within other atoms, Chemistry would get harder to teach.
We want this API to be understandable to Application Developers. I am
afraid of simplifying matters too much, and making things a bit too
abstract.
Understood, but I actually think that the Component inside Component
approach would work quite well with a simple "component type" attribute
of the Component resource.
In your particle physics example, it would be the equivalent of saying
that an Atom is composed of subatomic particles, with those subatomic
particles having different types (hadrons, baryons, mesons, etc) and
those subatomic particles being composed of zero or more subatomic
particles of various types (neutrons, protons, fermions, bosons, etc).
In fact, particle physics has the concept of elementary particles --
those particles whose composition is unknown -- and composite particles
-- those particles that are composed of other particles. The congruence
between the taxonomy of particles and what I'm proposing is actually
remarkable :)
Elementary particle is like a Component with no sub Components
Composite particle is like a Component with sub Components.
Each particle has a type, and each Component would also have a type.
Other possibility:
Call an Assembly exactly what it is: ComponentGroup
Best,
-jay
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
