Open Stack

On 11/27/2013 10:15 PM, Adrian Otto wrote:
>
> On Nov 27, 2013, at 11:27 AM, Jay Pipes <jaypipes at gmail.com> wrote:
>
>> On 11/27/2013 02:03 PM, Adrian Otto wrote:
>>> Jay,
>>>
>>> On Nov 27, 2013, at 10:36 AM, Jay Pipes <jaypipes at 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