Open Stack

Looks like most terms would have some ambiguity to them.  Regardless of what we decide on - maybe Application can stay after all - we need a crisp definition of the term, preferably with an example that illustrates the terminology and puts Application in context of different versions of the same applications, instances of the application.  

Great discussion!

Regards,
Tom.

-----Original Message-----
From: Alex Heneveld [mailto:alex.heneveld at cloudsoftcorp.com] 
Sent: Wednesday, November 27, 2013 11:32
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Solum] Definition feedback


Personally "Application" gets my vote as the conceptual "top level" 
unit, with the best combination of some meaning and not too much ambiguity.  At least so far.  As Tom notes there is some ambiguity ... 
not sure we can avoid that altogether but worth some brainstorming.

"Project" is what I had originally proposed to avoid the confusion with running app instances (assemblies) but that is even less descriptive and has meanings elsewhere.

"Package" feels too low level, I agree.

"Product" is perhaps an alternative though also not ideal.

--A


On 27/11/2013 06:31, Clayton Coleman wrote:
>
>> On Nov 26, 2013, at 11:10 PM, Adrian Otto <adrian.otto at rackspace.com> wrote:
>>
>>
>>
>>> On Nov 26, 2013, at 4:20 PM, "Clayton Coleman" <ccoleman at redhat.com> wrote:
>>>
>>>
>>>
>>>> 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.
>> All good points. This is why I like having these discussions with such a diverse group. I am still open to considering different terminology, accepting that whatever we pick to call things it will feel like a compromise for some of us. Any other thoughts on revisiting this name, or should we stick with application for now, and address this with more documentation to further clarify the meaning of the various abstracts?
> I think Tom's point on this is valid - the "app" resource is more of a factory or template for your app at first.  However, I could easily imagine interaction patterns that imply a cohesive unit over time, but those are hard to argue about until we've got more direct use cases and client interaction drawn up.
>
> For instance, if someone starts by creating an assembly right off the bat the application might not really be relevant, but if the client forces people to develop a plan first (either by helping them build it or pulling from operator templates) and then iterate on that plan directly (deploy app to env), a user might feel like the app is a stronger concept.
>
>>>>> 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
>>> _______________________________________________
>>> 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
> _______________________________________________
> 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