Open Stack

> On Nov 26, 2013, at 6:30 PM, Adrian Otto <adrian.otto at rackspace.com> wrote:
> 
> 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.

Package is a bit fraught given its overlap with other programming concepts:

Python Dev: How do I get my django app up in production?
Admin: You can create a new package for it.
Python Dev: You mean with an __init__.py file?

Admin: Go create your package in horizon so you can deploy it.
Java Dev: Ok, I ran Create Package from eclipse
(Hours of humorous miscommunication ensue)

Solum Admin: Go update the package for Bob's app.
Other Admin: I ran "yum update" but nothing happened...

If application is generic, that might be a good thing.  I'm not sure there are too many words that can accurately describe a Java WAR, a Ruby on Rails site, a Jenkins server, a massive service oriented architecture, or a worker queue processing log data at the same time.  Server and site are too specific or in use in openstack already, program is too singular.

At the end of the day someone has to explain these terms to a large number of end users (developers) - would hope we can pick a name that is recognizable to most of them immediately, because they're going to pick the option that looks the most familiar to them and try it first.

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

Or a part of one.

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