----- 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'. > >>>> 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@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 > > _______________________________________________ > > 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