Open Stack

>-----Original Message-----
>From: Adrian Otto [mailto:adrian.otto at rackspace.com]
>Sent: Wednesday, November 27, 2013 0:28
>To: OpenStack Development Mailing List (not for usage questions)
>Subject: Re: [openstack-dev] [Solum] Definition feedback
>
>Tom,
>
>On Nov 26, 2013, at 12:09 PM, "Tom Deckers (tdeckers)"
><tdeckers at cisco.com>
> wrote:
>
>> Hi All,
>>
>> Few comments on the Definitions blueprint [1]:
>>
>> 1. I'd propose to alter the term 'Application' to either 'Application Package'
>or 'Package'.  Application isn't very descriptive and can be confusing to some
>with the actual deployed instance, etc.
>
>I think that's a sensible suggestion. I'm open to using Package, as that's an
>accurate description of what an Application is currently conceived of.
>>
>> 2. It should be possible for the package to be self-contained, in order to
>distribute application definitions.   As such, instead of using a repo, source
>code might come with the package itself.  Has this been considered as a
>blueprint: deploy code/binaries that are in a zip, rather than a repo?  Maybe
>Artifact serves this purpose?
>
>The API should allow you to deploy something directly from a source code
>repo without packaging anything up. It should also allow you to present some
>static deployment artifacts (container image, zip file, etc.) for code that has
>already been built/tested.
>
>> 3. Artifact has not been called out as a top-level noun.  It probably should
>and get a proper definition.
>
>Good idea, I will add a definition for it.
>
>> 4. Plan is described as deployment plan, but then it's also referenced in the
>description of 'Build'.  Plan seems to have a dual meaning, which is fine, but
>that should be called out explicitly.  Plan is not synonymous with deployment
>plan, rather we have a deployment plan and a build plan.  Those two together
>can be 'the plan'.
>
>Currently Plan does have a dual meaning, but it may make sense to split each
>out if they are different enough. I'm open to considering ideas on this.
>
>> 5. Operations.  The definition states that definitions can be added to a
>Service too.  Since the Service is provided by the platform, I assume it already
>comes with operations predefined.
>
>Yes, the service provider owns services that are provided by the Platform, and
>can extend them, where users may not. However, a user may register his/her
>own Services within the context of a given tenant account, and those can be
>extended and managed. In that case, you can actually connect Operations to
>Services as a tenant. So this is really a question of what scope the Service
>belongs to.
>
>> 6. Operations. A descriptor should exist that can be used for registration of
>the deployed assembly into a catalog.  The descriptor should contain basic
>information about the exposed functional API and management API (e.g.
>Operations too).
>
>An Assembly is a running group of cloud resources (a whole networked
>application). A listing of those is exposed through the Assemblies resource.
>
>A Plan is a rubber stamp for producing new Assemblies, and can also be listed
>through the Plans resource. Any plan can be easily converted to an Assembly
>with an API call.
>
>Were you thinking that we should have a catalog beyond these listings?
>Please elaborate on what you have in mind. I agree that any catalog should
>provide a way to resolve through to a resources registered Operations. If the
>current design prohibits this in any way, then I'd like to revise that.

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).


>
>> This leads to the next point:
>>
>> 7. Package blueprint.  The Application Package might require its own
>blueprint to define how it's composed.  I can see how the Package is used to
>distribute/share an application.  The blueprint should define a well-known
>format.
>
>Yes, we have a concept of this that I'm working to express in writing. Think of
>the relation between HOT files and Heat. We will have a similar relation of Plan
>files to Solum. I will be borrowing concepts from CAMP, which has fully
>specified a format from an open standards perspective that should be well
>suited for this purpose.
>
>Thanks,
>
>Adrian
>
>> If the above makes sense, I can take a stab at an revised diagram.
>>
>> Regards,
>> Tom Deckers.
>>
>> [1] https://blueprints.launchpad.net/solum/+spec/definitions
>>
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev