On 11/27/2013 10:15 PM, Adrian Otto wrote:
On Nov 27, 2013, at 11:27 AM, Jay Pipes <jaypi...@gmail.com> wrote:
On 11/27/2013 02:03 PM, Adrian Otto wrote:
Jay,
On Nov 27, 2013, at 10:36 AM, Jay Pipes <jaypi...@gmail.com>
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.
Yes, this is precisely my point. I'm aiming for elementary Chemistry,
and you're aiming for Particle Physics.
LOL. Touché.
Other possibility:
Call an Assembly exactly what it is: ComponentGroup
I'm open to revisiting more possible names for this besides Assembly,
but I do strongly believe that the top level grouping should be it's
own thing, and should not just be a self referential arrangement of
the same type of resources. I'd like it to convey the idea that an
Assembly is the running instance of the complete application, and all
of its various parts. I'm not convinced that componentGroup conveys
that.
Fair enough :)
-jay
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
