[openstack-dev] [solum] use of the plan for m1

Adrian Otto adrian.otto at rackspace.com
Wed Mar 5 04:41:27 UTC 2014


Angus,

Please include a solum-dsl-version attribute in all examples. That can default to "current".

It would also be wise to have a language pack attribute as Devdatta suggested. Then we don't need to bump the version to support it later. The default value for solum-language-pack should be "auto" so If you omit it then you are relying on Solum to auto-detect the language. Users' mileage may vary depending on how sophisticated we make that detection code. If only one language pack is loaded, then we can always guess right ;-)

Cheers,

Adrian

> On Mar 4, 2014, at 7:26 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



More information about the OpenStack-dev mailing list