Re: [openstack-dev] [solum] use of the plan for m1
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
Re: [openstack-dev] [solum] use of the plan for m1
+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
Re: [openstack-dev] [solum] use of the plan for m1
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.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
