+1 for using a simple plan file for M1.
I agree, the language pack id would need to be part of the plan file.
-Murali
On Mar 4, 2014, at 9:20 PM, devdatta kulkarni <devdatta.kulka...@rackspace.com>
wrote:
> 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
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
