I support this approach. 

Customization of build and deploy lifecycle actions depends on
the ability to register different kinds of services for performing
these actions. I can imagine that operators would want to provide
such services as part of their Solum install. Then, app developers
would be able to find about such services and refer to them in
their application descriptor (may be a plan file, may be
something else). However, for m1, I agree that we should go with
the view that build and deploy services are not externalized, but are
available as default services in Solum.

About the proposed simpler descriptor -- the only question I have is about
the language-pack to use to build the app. Won't we need it in the
application descriptor? So I propose:

artifacts:
- name: My Python App
   artifact_type: application.heroku
   content: { href: http://github.com/some/project }
   language-pack: <language-pack-id>

- Devdatta


-----Original Message-----
From: "Angus Salkeld" <angus.salk...@rackspace.com>
Sent: Tuesday, March 4, 2014 8:52pm
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [solum] use of the plan for m1

Hi all

I just wanted to clarify our use of the camp plan file (esp. for m1).

Up until now I have been under the impression that use the plan
to describe the app lifecycle (build/test/deploy) and the contents
of the app.

After attempting to write code that converts plans like this into
heat templates started to think that this is not a good idea as
it is mixing two ideas from very different areas. It also makes
the resulting plan complex.

I suggest we move from some of the plans suggested here:
https://etherpad.openstack.org/p/solum-demystified

to a very simple:
artifacts:
- name: My Python App
   artifact_type: application.heroku
   content: { href: http://github.com/some/project }

For m1 we can assume a lifecycle of build and deploy. After that
we can figure out how we would want to expose the lifecycle
choices/customization to the user.

Thoughts?

-Angus

_______________________________________________
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

Reply via email to