Open Stack

----- 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.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
>