Re: [openstack-dev] [Solum] Definition feedback
On 11/27/2013 10:15 PM, Adrian Otto wrote: On Nov 27, 2013, at 11:27 AM, Jay Pipes jaypi...@gmail.com wrote: On 11/27/2013 02:03 PM, Adrian Otto wrote: Jay, On Nov 27, 2013, at 10:36 AM, Jay Pipes jaypi...@gmail.com wrote: On 11/27/2013 06:23 AM, Tom Deckers (tdeckers) wrote: 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). Another thought around the naming of Assembly... there's no reason why the API cannot just ditch the entire notion of an assembly, and just use Component in a self-referential way. In other words, an Application (or whatever is agree on for that resource name) contains one or more Components. Components may further be composed of one or more (sub)Components, which themselves may be composed of further (sub)Components. That way you keep the notion of a Component as generic and encompassing as possible and allow for an unlimited generic hierarchy of Component resources to comprise an Application. As currently proposed, an Assembly (a top level grouping of Components) requires only one Component, but may contain many. The question is whether we should even have an Assembly. I admit that Assembly is a new term, and therefore requires definition, explanation, and examples. However, I think eliminating it and just using Components is getting a bit too abstract, and requires a bit too much explanation. I consider this subject analogous to the fundamentals concepts of Chemistry. Imagine trying to describe a molecule by only using the concept of an atom. Each atom can be different, and have more or less electrons etc. But if we did not have the concept of a molecule (a top level grouping of atoms), and tried to explain them as atoms contained within other atoms, Chemistry would get harder to teach. We want this API to be understandable to Application Developers. I am afraid of simplifying matters too much, and making things a bit too abstract. Understood, but I actually think that the Component inside Component approach would work quite well with a simple component type attribute of the Component resource. In your particle physics example, it would be the equivalent of saying that an Atom is composed of subatomic particles, with those subatomic particles having different types (hadrons, baryons, mesons, etc) and those subatomic particles being composed of zero or more subatomic particles of various types (neutrons, protons, fermions, bosons, etc). In fact, particle physics has the concept of elementary particles -- those particles whose composition is unknown -- and composite particles -- those particles that are composed of other particles. The congruence between the taxonomy of particles and what I'm proposing is actually remarkable :) Elementary particle is like a Component with no sub Components Composite particle is like a Component with sub Components. Each particle has a type, and each Component would also have a type. Yes, this is precisely my point. I'm aiming for elementary Chemistry, and you're aiming for Particle Physics. LOL. Touché. Other possibility: Call an Assembly exactly what it is: ComponentGroup I'm open to revisiting more possible names for this besides Assembly, but I do strongly believe that the top level grouping should be it's own thing, and should not just be a self referential arrangement of the same type of resources. I'd like it to convey the idea that an Assembly is the running instance of the complete application, and all of its various parts. I'm not convinced that componentGroup conveys that. Fair enough :) -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org
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 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.
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
Re: [openstack-dev] [Solum] Definition feedback
- Original Message - 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. And for those not following openstack-dev it looks like there is consensus developing about tenant - project in the REST APIs (not yet closed, but did not see much if any objections). 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 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'.
Re: [openstack-dev] [Solum] Definition feedback
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
Re: [openstack-dev] [Solum] Definition feedback
On 11/27/2013 06:23 AM, Tom Deckers (tdeckers) wrote: 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). Another thought around the naming of Assembly... there's no reason why the API cannot just ditch the entire notion of an assembly, and just use Component in a self-referential way. In other words, an Application (or whatever is agree on for that resource name) contains one or more Components. Components may further be composed of one or more (sub)Components, which themselves may be composed of further (sub)Components. That way you keep the notion of a Component as generic and encompassing as possible and allow for an unlimited generic hierarchy of Component resources to comprise an Application. Best, -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Solum] Definition feedback
Jay, On Nov 27, 2013, at 10:36 AM, Jay Pipes jaypi...@gmail.com wrote: On 11/27/2013 06:23 AM, Tom Deckers (tdeckers) wrote: 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). Another thought around the naming of Assembly... there's no reason why the API cannot just ditch the entire notion of an assembly, and just use Component in a self-referential way. In other words, an Application (or whatever is agree on for that resource name) contains one or more Components. Components may further be composed of one or more (sub)Components, which themselves may be composed of further (sub)Components. That way you keep the notion of a Component as generic and encompassing as possible and allow for an unlimited generic hierarchy of Component resources to comprise an Application. As currently proposed, an Assembly (a top level grouping of Components) requires only one Component, but may contain many. The question is whether we should even have an Assembly. I admit that Assembly is a new term, and therefore requires definition, explanation, and examples. However, I think eliminating it and just using Components is getting a bit too abstract, and requires a bit too much explanation. I consider this subject analogous to the fundamentals concepts of Chemistry. Imagine trying to describe a molecule by only using the concept of an atom. Each atom can be different, and have more or less electrons etc. But if we did not have the concept of a molecule (a top level grouping of atoms), and tried to explain them as atoms contained within other atoms, Chemistry would get harder to teach. We want this API to be understandable to Application Developers. I am afraid of simplifying matters too much, and making things a bit too abstract. Thanks, Adrian Best, -jay ___ 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
Re: [openstack-dev] [Solum] Definition feedback
On 11/27/2013 02:03 PM, Adrian Otto wrote: Jay, On Nov 27, 2013, at 10:36 AM, Jay Pipes jaypi...@gmail.com wrote: On 11/27/2013 06:23 AM, Tom Deckers (tdeckers) wrote: 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). Another thought around the naming of Assembly... there's no reason why the API cannot just ditch the entire notion of an assembly, and just use Component in a self-referential way. In other words, an Application (or whatever is agree on for that resource name) contains one or more Components. Components may further be composed of one or more (sub)Components, which themselves may be composed of further (sub)Components. That way you keep the notion of a Component as generic and encompassing as possible and allow for an unlimited generic hierarchy of Component resources to comprise an Application. As currently proposed, an Assembly (a top level grouping of Components) requires only one Component, but may contain many. The question is whether we should even have an Assembly. I admit that Assembly is a new term, and therefore requires definition, explanation, and examples. However, I think eliminating it and just using Components is getting a bit too abstract, and requires a bit too much explanation. I consider this subject analogous to the fundamentals concepts of Chemistry. Imagine trying to describe a molecule by only using the concept of an atom. Each atom can be different, and have more or less electrons etc. But if we did not have the concept of a molecule (a top level grouping of atoms), and tried to explain them as atoms contained within other atoms, Chemistry would get harder to teach. We want this API to be understandable to Application Developers. I am afraid of simplifying matters too much, and making things a bit too abstract. Understood, but I actually think that the Component inside Component approach would work quite well with a simple component type attribute of the Component resource. In your particle physics example, it would be the equivalent of saying that an Atom is composed of subatomic particles, with those subatomic particles having different types (hadrons, baryons, mesons, etc) and those subatomic particles being composed of zero or more subatomic particles of various types (neutrons, protons, fermions, bosons, etc). In fact, particle physics has the concept of elementary particles -- those particles whose composition is unknown -- and composite particles -- those particles that are composed of other particles. The congruence between the taxonomy of particles and what I'm proposing is actually remarkable :) Elementary particle is like a Component with no sub Components Composite particle is like a Component with sub Components. Each particle has a type, and each Component would also have a type. Other possibility: Call an Assembly exactly what it is: ComponentGroup Best, -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Solum] Definition feedback
On Nov 27, 2013, at 11:27 AM, Jay Pipes jaypi...@gmail.com wrote: On 11/27/2013 02:03 PM, Adrian Otto wrote: Jay, On Nov 27, 2013, at 10:36 AM, Jay Pipes jaypi...@gmail.com wrote: On 11/27/2013 06:23 AM, Tom Deckers (tdeckers) wrote: 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). Another thought around the naming of Assembly... there's no reason why the API cannot just ditch the entire notion of an assembly, and just use Component in a self-referential way. In other words, an Application (or whatever is agree on for that resource name) contains one or more Components. Components may further be composed of one or more (sub)Components, which themselves may be composed of further (sub)Components. That way you keep the notion of a Component as generic and encompassing as possible and allow for an unlimited generic hierarchy of Component resources to comprise an Application. As currently proposed, an Assembly (a top level grouping of Components) requires only one Component, but may contain many. The question is whether we should even have an Assembly. I admit that Assembly is a new term, and therefore requires definition, explanation, and examples. However, I think eliminating it and just using Components is getting a bit too abstract, and requires a bit too much explanation. I consider this subject analogous to the fundamentals concepts of Chemistry. Imagine trying to describe a molecule by only using the concept of an atom. Each atom can be different, and have more or less electrons etc. But if we did not have the concept of a molecule (a top level grouping of atoms), and tried to explain them as atoms contained within other atoms, Chemistry would get harder to teach. We want this API to be understandable to Application Developers. I am afraid of simplifying matters too much, and making things a bit too abstract. Understood, but I actually think that the Component inside Component approach would work quite well with a simple component type attribute of the Component resource. In your particle physics example, it would be the equivalent of saying that an Atom is composed of subatomic particles, with those subatomic particles having different types (hadrons, baryons, mesons, etc) and those subatomic particles being composed of zero or more subatomic particles of various types (neutrons, protons, fermions, bosons, etc). In fact, particle physics has the concept of elementary particles -- those particles whose composition is unknown -- and composite particles -- those particles that are composed of other particles. The congruence between the taxonomy of particles and what I'm proposing is actually remarkable :) Elementary particle is like a Component with no sub Components Composite particle is like a Component with sub Components. Each particle has a type, and each Component would also have a type. Yes, this is precisely my point. I'm aiming for elementary Chemistry, and you're aiming for Particle Physics. Other possibility: Call an Assembly exactly what it is: ComponentGroup I'm open to revisiting more possible names for this besides Assembly, but I do strongly believe that the top level grouping should be it's own thing, and should not just be a self referential arrangement of the same type of resources. I'd like it to convey the idea that an Assembly is the running instance of the complete application, and all of its various parts. I'm not convinced that componentGroup conveys that. Best, -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org
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. 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
Re: [openstack-dev] [Solum] Definition feedback
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. 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,
Re: [openstack-dev] [Solum] Definition feedback
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? 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
Re: [openstack-dev] [Solum] Definition feedback
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 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
