Open Stack

+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.kulkarni at 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.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
> 
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev