[openstack-dev] [solum] use of the plan for m1
devdatta kulkarni
devdatta.kulkarni at rackspace.com
Wed Mar 5 03:20:18 UTC 2014
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.salkeld at rackspace.com>
Sent: Tuesday, March 4, 2014 8:52pm
To: openstack-dev at 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 at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
More information about the OpenStack-dev
mailing list