Re: [openstack-dev] [Solum] Definition feedback
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.henev...@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.o...@rackspace.com wrote: On Nov 26, 2013, at 4:20 PM, Clayton Coleman ccole...@redhat.com wrote: On Nov 26, 2013, at 6:30 PM, Adrian Otto adrian.o...@rackspace.com wrote: Tom, On Nov 26, 2013, at 12:09 PM, Tom Deckers (tdeckers) tdeck...@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
Re: [openstack-dev] [Solum] Definition feedback
-Original Message- From: Adrian Otto [mailto:adrian.o...@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) tdeck...@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
