On Nov 27, 2013, at 3:23 AM, "Tom Deckers (tdeckers)" <tdeck...@cisco.com> wrote:
>> -----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 think I understand what you are getting at now. This is where the concept of Services come in. The Services resource is a collection of Service resources, each of which are some service/thing/capability that wither the platform provider is offering, or that the tenant/user has created. For example, suppose I have an "Adrian API" that I create a Plan for, and launch into an Assembly. Now I can take that Assembly, and list it's connection specifics in a Service. Now that Assembly can be found/used by other Assemblies. So the next "Blah App" that comes along can call for a service named "Adrian API" and will be wired up to that existing running assembly. If I added support for multi-tenancy to "Adrian App", I might actually get a slice of that service using a particular tenant/app id. > 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. The Plans resources is where you could browse Applications, and the Services resource is where you could browse Assemblies (and platform provider hosted services). > As a service consumer, I should be able to look at the 'Applications' listed > in the Openstack environment and provision them. Low level things like data stores, queues, and similar system level building blocks can be offered as Services. Higher level things like "Awesome Shopping Cart App" could be pre-listed as Plans. > 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. I expect there are a variety of ways to handle this. My favorite is to allow parameters to be passed into a Plan to influence what the characteristics of the resulting assembly may be. For example, you might have a flavor enumerated as "gold", "silver", "bronze" that you express as a parameter, and that sets an attribute on the resulting Component that the model interpreter places in the Assembly. That would also cause the generated Heat template to size the cloud resources differently so the Compute/Container resources are bigger or smaller, etc. > 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 sounds like the Services resource. We will have querying on the Services collection, so you can query it for Services that have a particular named attribute. For example, if you named an attribute "Capability" and set the value to "Adrian API", then you could do a query against the Services collection to get a list of Service resources with that attribute value set. You might also query or combinations such as Capability="Adrian API" and "Flavor=Gold". These would be called out as Requirements in your Plan file. I'm getting a bit ahead of what we have written out in the API spec wiki, but that's currently WIP to document these concepts. I expect to finish that work soon. >>> 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@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
