https://wiki.openstack.org/w/api.php?action=feedcontributions&feedformat=atom&user=Rob-raymond 2026-06-29T09:24:33Z User contributions MediaWiki 1.28.2 https://wiki.openstack.org/w/index.php?title=Ceilometer/Contributing&diff=42694 2014-02-19T04:26:27Z

<p>Rob-raymond: /* Update documentation */</p> <hr /> <div><br /> = Contributing to Ceilometer =<br /> The developer documentation is starting to take shape within the source and is also published at http://docs.openstack.org/developer/ceilometer/ in a more friendly format.<br /> <br /> The project team hangs out on Freenode in the #openstack-metering channel, feel free to drop by and stay as long as you want to discuss your future implementation. We use the [[OpenStack]] General Mailing List for our email discussions tagging the the subject with [metering].<br /> <br /> The project team officially meets once a week, see [[Meetings/MeteringAgenda|Ceilometer's Meeting Agenda]]<br /> <br /> == Setting-up Ceilometer via devstack ==<br /> The easiest way to develop on Ceilometer is to use [http://devstack.org devstack].<br /> <br /> Edit your ''localrc'' file and add these lines to enable ''ceilometer'':<br /> <br /> <br /> &lt;pre&gt;&lt;nowiki&gt;#!highlight bash<br /> enable_service ceilometer-api<br /> enable_service ceilometer-collector<br /> enable_service ceilometer-acentral<br /> enable_service ceilometer-acompute&lt;/nowiki&gt;&lt;/pre&gt;<br /> <br /> <br /> == Possible tasks ==<br /> === Update documentation ===<br /> A good first step is to try following the documentation to set-up and configure Ceilometer to see if the documentation is wrong or out-dated.<br /> Once everything's working, the next step would be to read the rest of the documentation to see if everything that's written is still true. Anything that's not clear or might be missing should be fixed and updated.<br /> <br /> To update the documentation, the best way is to send a patch. But notifying the team via the [[MailingLists#Development_List|development mailing list]] or via IRC is fine too!<br /> <br /> === Close old fixed bugs ===<br /> Old bugs are nasty. Even when they are long dead, they clog bug views and render the lists unusable. Just look at old bugs and check if they still apply! If they don't, close them as ''[[FixReleased]]'' (if you can pinpoint when they were fixed) or ''Invalid'' (if you can't).<br /> <br /> === Fix bugs ===<br /> The best thing you can do is to kill a living bug. Just look at the list of ''Confirmed'' or ''Triaged'' and pick your target. Submit a change that fixes it. Ask for review help on the channel.<br /> <br /> === Review patches ===<br /> You can review patches on the Gerrit platform for [https://review.openstack.org/#/q/status:open+project:openstack/ceilometer,n,z ceilometer] and for [https://review.openstack.org/#/q/status:open+project:openstack/python-ceilometerclient,n,z python-ceilometerclient].<br /> <br /> === Triage incoming bugs ===<br /> It's sometimes hard to distinguish fresh bugs from false alarms. You can help by using your expertise or reproduction skills on ''New'' bugs. If you can confirm the issue, set the bug to ''Confirmed''. If you can fix it, read the previous entry. If you need more info from the reporter, set it to ''Incomplete''. And if it happens to not really be valid, set it to ''Invalid''!<br /> <br /> You can read more information about [[BugTriage|how to do bug triaging for OpenStack]].</div>

Rob-raymond https://wiki.openstack.org/w/index.php?title=Diesel&diff=40028 2014-01-18T03:13:18Z

<p>Rob-raymond: /* Diesel */</p> <hr /> <div>__NOTOC__<br /> <br /> = Mission =<br /> <br /> The mission of Diesel is to allow OpenStack clouds to run applications. The cloud administrator can control the non functional aspects, freeing up the application developer to focus on their application and its functionality.<br /> <br /> = Diesel =<br /> In the spirit of Google App Engine, Heroku, Engine Yard and others, Diesel runs web applications in the cloud. It can be used by cloud administrators to define the application types that they support. They are also responsible for defining through Diesel how these applications run on top of their cloud infrastructure. Diesel will control the availability and scalability of the web application deployment.<br /> <br /> Why Diesel? It is an engine that uses heat to run. With the added bonus that Vin Diesel can be the spokesperson.<br /> <br /> == How it works ==<br /> For each Diesel application type, there are heat templates associated for handling starting new instances to host applications and deploying application images to these instances.<br /> An application type can either be defined to be the sole tenant of an instance or define it to run in an instance along with other applications. Application isolation is achieved by docker or some sandboxing configuration depending on the environment.<br /> An application type example may be Ruby on Rails applications with dedicated instances.<br /> <br /> Users can define a new application to Diesel by choosing one of the application types. Part of the application is the URL that it will expose.<br /> When a user uploads a new version of the artifact as a Glance image, Diesel will find an existing instance or create a new instance to host the application. The image will be deployed to the image and configuration will be run. This new running application instance will be added to the load balancer.<br /> <br /> Using Ceilometer data and heat templates, application instances will be spun up or spun down based on demand and availability constraints.<br /> <br /> == Architecture ==<br /> Diesel is comprised of a python application that provides an OpenStack-native ReST API that exposes the Diesel data model,<br /> <br /> It will also include heat templates<br /> <br /> == Relations to other projects ==<br /> * Heat - Diesel uses heat to orchestrate creating new instances, scaling instances and shutting down instances<br /> * Trove - Diesel deployed applications may use trove to host their databases<br /> * Savanna - Savanna is to map reduce applications as Diesel is to web applications<br /> * Solum - Solum is focused on the development lifecycle for the application. The application may be one that Diesel can run.<br /> * Neutron - Load Balancer Service will be used. As application instances are started and stopped they will be added and removed from load balancer<br /> <br /> == Development ==<br /> An initial implementation with api exposing data model will be uploaded to stackforge ASAP</div>

Rob-raymond https://wiki.openstack.org/w/index.php?title=Diesel&diff=40027 2014-01-18T03:09:58Z

<p>Rob-raymond: /* Mission */</p> <hr /> <div>__NOTOC__<br /> <br /> = Mission =<br /> <br /> The mission of Diesel is to allow OpenStack clouds to run applications. The cloud administrator can control the non functional aspects, freeing up the application developer to focus on their application and its functionality.<br /> <br /> = Diesel =<br /> In the spirit of Google App Engine, Heroku, Engine Yard and others, Diesel runs web application in the cloud. It can be used by cloud providers to define the application types that they support. They are also responsible for defining through Diesel how these applications run on top of their cloud infrastructure. Diesel will control the availability and scalability of the web application deployment.<br /> <br /> Why Diesel? It is an engine that uses heat to run. With the added bonus that Vin Diesel can be the spokesperson.<br /> <br /> == How it works ==<br /> For each Diesel application type, there are heat templates associated for handling starting new instances to host applications and deploying application images to these instances.<br /> An application type can either be defined to be the sole tenant of an instance or define it to run in an instance along with other applications. Application isolation is achieved by docker or some sandboxing configuration depending on the environment.<br /> An application type example may be Ruby on Rails applications with dedicated instances.<br /> <br /> Users can define a new application to Diesel by choosing one of the application types. Part of the application is the URL that it will expose.<br /> When a user uploads a new version of the artifact as a Glance image, Diesel will find an existing instance or create a new instance to host the application. The image will be deployed to the image and configuration will be run. This new running application instance will be added to the load balancer.<br /> <br /> Using Ceilometer data and heat templates, application instances will be spun up or spun down based on demand and availability constraints.<br /> <br /> == Architecture ==<br /> Diesel is comprised of a python application that provides an OpenStack-native ReST API that exposes the Diesel data model,<br /> <br /> It will also include heat templates<br /> <br /> == Relations to other projects ==<br /> * Heat - Diesel uses heat to orchestrate creating new instances, scaling instances and shutting down instances<br /> * Trove - Diesel deployed applications may use trove to host their databases<br /> * Savanna - Savanna is to map reduce applications as Diesel is to web applications<br /> * Solum - Solum is focused on the development lifecycle for the application. The application may be one that Diesel can run.<br /> * Neutron - Load Balancer Service will be used. As application instances are started and stopped they will be added and removed from load balancer</div>

Rob-raymond https://wiki.openstack.org/w/index.php?title=Diesel&diff=40026 2014-01-18T03:09:16Z

<p>Rob-raymond: /* Relation to other projects */</p> <hr /> <div>__NOTOC__<br /> <br /> = Mission =<br /> <br /> The mission of Diesel is to allow OpenStack clouds to run applications. The cloud administrator can control the non functional aspects freeing up the application developer to focus on their application and its functionality.<br /> <br /> = Diesel =<br /> In the spirit of Google App Engine, Heroku, Engine Yard and others, Diesel runs web application in the cloud. It can be used by cloud providers to define the application types that they support. They are also responsible for defining through Diesel how these applications run on top of their cloud infrastructure. Diesel will control the availability and scalability of the web application deployment.<br /> <br /> Why Diesel? It is an engine that uses heat to run. With the added bonus that Vin Diesel can be the spokesperson.<br /> <br /> == How it works ==<br /> For each Diesel application type, there are heat templates associated for handling starting new instances to host applications and deploying application images to these instances.<br /> An application type can either be defined to be the sole tenant of an instance or define it to run in an instance along with other applications. Application isolation is achieved by docker or some sandboxing configuration depending on the environment.<br /> An application type example may be Ruby on Rails applications with dedicated instances.<br /> <br /> Users can define a new application to Diesel by choosing one of the application types. Part of the application is the URL that it will expose.<br /> When a user uploads a new version of the artifact as a Glance image, Diesel will find an existing instance or create a new instance to host the application. The image will be deployed to the image and configuration will be run. This new running application instance will be added to the load balancer.<br /> <br /> Using Ceilometer data and heat templates, application instances will be spun up or spun down based on demand and availability constraints.<br /> <br /> == Architecture ==<br /> Diesel is comprised of a python application that provides an OpenStack-native ReST API that exposes the Diesel data model,<br /> <br /> It will also include heat templates<br /> <br /> == Relations to other projects ==<br /> * Heat - Diesel uses heat to orchestrate creating new instances, scaling instances and shutting down instances<br /> * Trove - Diesel deployed applications may use trove to host their databases<br /> * Savanna - Savanna is to map reduce applications as Diesel is to web applications<br /> * Solum - Solum is focused on the development lifecycle for the application. The application may be one that Diesel can run.<br /> * Neutron - Load Balancer Service will be used. As application instances are started and stopped they will be added and removed from load balancer</div>

Rob-raymond https://wiki.openstack.org/w/index.php?title=Diesel&diff=40025 2014-01-18T02:46:16Z

<p>Rob-raymond: /* Application Service */</p> <hr /> <div>__NOTOC__<br /> <br /> = Mission =<br /> <br /> The mission of Diesel is to allow OpenStack clouds to run applications. The cloud administrator can control the non functional aspects freeing up the application developer to focus on their application and its functionality.<br /> <br /> = Diesel =<br /> In the spirit of Google App Engine, Heroku, Engine Yard and others, Diesel runs web application in the cloud. It can be used by cloud providers to define the application types that they support. They are also responsible for defining through Diesel how these applications run on top of their cloud infrastructure. Diesel will control the availability and scalability of the web application deployment.<br /> <br /> Why Diesel? It is an engine that uses heat to run. With the added bonus that Vin Diesel can be the spokesperson.<br /> <br /> == How it works ==<br /> For each Diesel application type, there are heat templates associated for handling starting new instances to host applications and deploying application images to these instances.<br /> An application type can either be defined to be the sole tenant of an instance or define it to run in an instance along with other applications. Application isolation is achieved by docker or some sandboxing configuration depending on the environment.<br /> An application type example may be Ruby on Rails applications with dedicated instances.<br /> <br /> Users can define a new application to Diesel by choosing one of the application types. Part of the application is the URL that it will expose.<br /> When a user uploads a new version of the artifact as a Glance image, Diesel will find an existing instance or create a new instance to host the application. The image will be deployed to the image and configuration will be run. This new running application instance will be added to the load balancer.<br /> <br /> Using Ceilometer data and heat templates, application instances will be spun up or spun down based on demand and availability constraints.<br /> <br /> == Architecture ==<br /> Diesel is comprised of a python application that provides an OpenStack-native ReST API that exposes the Diesel data model,<br /> <br /> It will also include heat templates<br /> <br /> == Relation to other projects ==<br /> * Heat - Diesel uses heat to orchestrate creating new instances, scaling instances and shutting down instances<br /> * Trove - Diesel deployed applications may use trove to host their databases<br /> * Savanna - Savanna is to map reduce applications as Diesel is to web applications<br /> * Solum - Solum is focused on the development lifecycle for the application. The application may be one that Diesel can run.<br /> * Neutron - Load Balancer Service will be used. As application instances are started and stopped they will be added and removed from load balancer</div>

Rob-raymond https://wiki.openstack.org/w/index.php?title=Diesel&diff=40024 2014-01-18T02:29:49Z

<p>Rob-raymond: /* How it works */</p> <hr /> <div>__NOTOC__<br /> <br /> = Application Service =<br /> <br /> The mission of the Application Service is to allow OpenStack clouds to run applications. The cloud administrator can control the non functional aspects freeing up the application developer to focus on their application and its functionality.<br /> <br /> = Diesel =<br /> In the spirit of Google App Engine, Heroku, Engine Yard and others, Diesel runs web application in the cloud. It can be used by cloud providers to define the application types that they support. They are also responsible for defining through Diesel how these applications run on top of their cloud infrastructure. Diesel will control the availability and scalability of the web application deployment.<br /> <br /> Why Diesel? It is an engine that uses heat to run. With the added bonus that Vin Diesel can be the spokesperson.<br /> <br /> == How it works ==<br /> For each Diesel application type, there are heat templates associated for handling starting new instances to host applications and deploying application images to these instances.<br /> An application type can either be defined to be the sole tenant of an instance or define it to run in an instance along with other applications. Application isolation is achieved by docker or some sandboxing configuration depending on the environment.<br /> An application type example may be Ruby on Rails applications with dedicated instances.<br /> <br /> Users can define a new application to Diesel by choosing one of the application types. Part of the application is the URL that it will expose.<br /> When a user uploads a new version of the artifact as a Glance image, Diesel will find an existing instance or create a new instance to host the application. The image will be deployed to the image and configuration will be run. This new running application instance will be added to the load balancer.<br /> <br /> Using Ceilometer data and heat templates, application instances will be spun up or spun down based on demand and availability constraints.<br /> <br /> == Architecture ==<br /> Diesel is comprised of a python application that provides an OpenStack-native ReST API that exposes the Diesel data model,<br /> <br /> It will also include heat templates<br /> <br /> == Relation to other projects ==<br /> * Heat - Diesel uses heat to orchestrate creating new instances, scaling instances and shutting down instances<br /> * Trove - Diesel deployed applications may use trove to host their databases<br /> * Savanna - Savanna is to map reduce applications as Diesel is to web applications<br /> * Solum - Solum is focused on the development lifecycle for the application. The application may be one that Diesel can run.<br /> * Neutron - Load Balancer Service will be used. As application instances are started and stopped they will be added and removed from load balancer</div>

Rob-raymond https://wiki.openstack.org/w/index.php?title=Diesel&diff=40023 2014-01-18T02:29:09Z

<p>Rob-raymond: /* Diesel */</p> <hr /> <div>__NOTOC__<br /> <br /> = Application Service =<br /> <br /> The mission of the Application Service is to allow OpenStack clouds to run applications. The cloud administrator can control the non functional aspects freeing up the application developer to focus on their application and its functionality.<br /> <br /> = Diesel =<br /> In the spirit of Google App Engine, Heroku, Engine Yard and others, Diesel runs web application in the cloud. It can be used by cloud providers to define the application types that they support. They are also responsible for defining through Diesel how these applications run on top of their cloud infrastructure. Diesel will control the availability and scalability of the web application deployment.<br /> <br /> Why Diesel? It is an engine that uses heat to run. With the added bonus that Vin Diesel can be the spokesperson.<br /> <br /> == How it works ==<br /> For each application type, there are heat templates associated for handling starting new instances to host applications and deploying application images to these instances.<br /> An application type can either be defined to be the sole tenant of an instance or define it to run in an instance along with other applications. Application isolation is achieved by docker or some sandboxing configuration depending on the environment.<br /> An application type example may be Ruby on Rails applications with dedicated instances.<br /> <br /> Users can define a new application to Diesel by choosing one of the application types. Part of the application is the URL that it will expose.<br /> When a user uploads a new version of the artifact as a Glance image, Diesel will find an existing instance or create a new instance to host the application. The image will be deployed to the image and configuration will be run. This new running application instance will be added to the load balancer.<br /> <br /> Using Ceilometer data and heat templates, application instances will be spun up or spun down based on demand and availability constraints.<br /> <br /> == Architecture ==<br /> Diesel is comprised of a python application that provides an OpenStack-native ReST API that exposes the Diesel data model,<br /> <br /> It will also include heat templates<br /> <br /> == Relation to other projects ==<br /> * Heat - Diesel uses heat to orchestrate creating new instances, scaling instances and shutting down instances<br /> * Trove - Diesel deployed applications may use trove to host their databases<br /> * Savanna - Savanna is to map reduce applications as Diesel is to web applications<br /> * Solum - Solum is focused on the development lifecycle for the application. The application may be one that Diesel can run.<br /> * Neutron - Load Balancer Service will be used. As application instances are started and stopped they will be added and removed from load balancer</div>

Rob-raymond https://wiki.openstack.org/w/index.php?title=Diesel&diff=40022 2014-01-18T02:28:38Z

<p>Rob-raymond: /* Relation to other projects */</p> <hr /> <div>__NOTOC__<br /> <br /> = Application Service =<br /> <br /> The mission of the Application Service is to allow OpenStack clouds to run applications. The cloud administrator can control the non functional aspects freeing up the application developer to focus on their application and its functionality.<br /> <br /> = Diesel =<br /> In the spirit of Google App Engine, Heroku, Engine Yard and others, Diesel provides web application in the cloud. It can be used by cloud providers to define the application types that they support. They are also responsible for defining through Diesel how these applications run on top of their cloud infrastructure. Diesel will control the availability and scalability of the web application deployment.<br /> <br /> Why Diesel? It is an engine that uses heat to run. With the added bonus that Vin Diesel can be the spokesperson.<br /> <br /> == How it works ==<br /> For each application type, there are heat templates associated for handling starting new instances to host applications and deploying application images to these instances.<br /> An application type can either be defined to be the sole tenant of an instance or define it to run in an instance along with other applications. Application isolation is achieved by docker or some sandboxing configuration depending on the environment.<br /> An application type example may be Ruby on Rails applications with dedicated instances.<br /> <br /> Users can define a new application to Diesel by choosing one of the application types. Part of the application is the URL that it will expose.<br /> When a user uploads a new version of the artifact as a Glance image, Diesel will find an existing instance or create a new instance to host the application. The image will be deployed to the image and configuration will be run. This new running application instance will be added to the load balancer.<br /> <br /> Using Ceilometer data and heat templates, application instances will be spun up or spun down based on demand and availability constraints.<br /> <br /> == Architecture ==<br /> Diesel is comprised of a python application that provides an OpenStack-native ReST API that exposes the Diesel data model,<br /> <br /> It will also include heat templates<br /> <br /> == Relation to other projects ==<br /> * Heat - Diesel uses heat to orchestrate creating new instances, scaling instances and shutting down instances<br /> * Trove - Diesel deployed applications may use trove to host their databases<br /> * Savanna - Savanna is to map reduce applications as Diesel is to web applications<br /> * Solum - Solum is focused on the development lifecycle for the application. The application may be one that Diesel can run.<br /> * Neutron - Load Balancer Service will be used. As application instances are started and stopped they will be added and removed from load balancer</div>

Rob-raymond https://wiki.openstack.org/w/index.php?title=Diesel&diff=40021 2014-01-18T02:27:00Z

<p>Rob-raymond: /* Diesel */</p> <hr /> <div>__NOTOC__<br /> <br /> = Application Service =<br /> <br /> The mission of the Application Service is to allow OpenStack clouds to run applications. The cloud administrator can control the non functional aspects freeing up the application developer to focus on their application and its functionality.<br /> <br /> = Diesel =<br /> In the spirit of Google App Engine, Heroku, Engine Yard and others, Diesel provides web application in the cloud. It can be used by cloud providers to define the application types that they support. They are also responsible for defining through Diesel how these applications run on top of their cloud infrastructure. Diesel will control the availability and scalability of the web application deployment.<br /> <br /> Why Diesel? It is an engine that uses heat to run. With the added bonus that Vin Diesel can be the spokesperson.<br /> <br /> == How it works ==<br /> For each application type, there are heat templates associated for handling starting new instances to host applications and deploying application images to these instances.<br /> An application type can either be defined to be the sole tenant of an instance or define it to run in an instance along with other applications. Application isolation is achieved by docker or some sandboxing configuration depending on the environment.<br /> An application type example may be Ruby on Rails applications with dedicated instances.<br /> <br /> Users can define a new application to Diesel by choosing one of the application types. Part of the application is the URL that it will expose.<br /> When a user uploads a new version of the artifact as a Glance image, Diesel will find an existing instance or create a new instance to host the application. The image will be deployed to the image and configuration will be run. This new running application instance will be added to the load balancer.<br /> <br /> Using Ceilometer data and heat templates, application instances will be spun up or spun down based on demand and availability constraints.<br /> <br /> == Architecture ==<br /> Diesel is comprised of a python application that provides an OpenStack-native ReST API that exposes the Diesel data model,<br /> <br /> It will also include heat templates<br /> <br /> == Relation to other projects ==<br /> * Heat - Diesel uses heat to orchestrate creating new instances, scaling instances and shutting down instances<br /> * Trove - Diesel deployed applications may use trove to host their databases<br /> * Savanna - Savanna is to map reduce applications as Diesel is to web applications<br /> * Solum - Solum is focused on the development lifecycle for the application. Diesel may be an environment that they deploy to.<br /> * Neutron - Load Balancer Service will be used. As application instances are started and stopped they will be added and removed from load balancer</div>

Rob-raymond https://wiki.openstack.org/w/index.php?title=Diesel&diff=40020 2014-01-18T02:04:04Z

<p>Rob-raymond: /* Relation to other projects */</p> <hr /> <div>__NOTOC__<br /> <br /> = Application Service =<br /> <br /> The mission of the Application Service is to allow OpenStack clouds to run applications. The cloud administrator can control the non functional aspects freeing up the application developer to focus on their application and its functionality.<br /> <br /> = Diesel =<br /> In the spirit of Google App Engine, Heroku, Engine Yard and others, Diesel can be used by cloud providers to define the application types that they support. They are also responsible for defining through Diesel how these applications run on top of their cloud infrastructure. <br /> <br /> Why Diesel? It is an engine that uses heat to run. With the added bonus that Vin Diesel can be the spokesperson.<br /> <br /> == How it works ==<br /> For each application type, there are heat templates associated for handling starting new instances to host applications and deploying application images to these instances.<br /> An application type can either be defined to be the sole tenant of an instance or define it to run in an instance along with other applications. Application isolation is achieved by docker or some sandboxing configuration depending on the environment.<br /> <br /> Users can define a new application to Diesel by choosing one of the application types. Part of the application is the URL that it will expose.<br /> When a user uploads a new version of the artifact as a Cinder image, Diesel will find an existing instance or create a new instance to host the application. The image will be deployed to the image and configuration will be run. This new running application instance will be added to the load balancer.<br /> <br /> Using Ceilometer data and heat templates, application instances will be spun up or spun down based on demand and availability constraints.<br /> <br /> == Architecture ==<br /> <br /> == Relation to other projects ==<br /> * Heat - Diesel uses heat to orchestrate creating new instances, scaling instances and shutting down instances<br /> * Trove - Diesel deployed applications may use trove to host their databases<br /> * Savanna - Savanna is to map reduce applications as Diesel is to web applications<br /> * Solum - Solum is focused on the development lifecycle for the application. Diesel may be an environment that they deploy to.<br /> * Neutron - Load Balancer Service will be used. As application instances are started and stopped they will be added and removed from load balancer</div>

Rob-raymond https://wiki.openstack.org/w/index.php?title=Diesel&diff=40019 2014-01-18T01:34:02Z

<p>Rob-raymond: Initial Diesel project page</p> <hr /> <div>__NOTOC__<br /> <br /> = Application Service =<br /> <br /> The mission of the Application Service is to allow OpenStack clouds to run applications. The cloud administrator can control the non functional aspects freeing up the application developer to focus on their application and its functionality.<br /> <br /> = Diesel =<br /> In the spirit of Google App Engine, Heroku, Engine Yard and others, Diesel can be used by cloud providers to define the application types that they support. They are also responsible for defining through Diesel how these applications run on top of their cloud infrastructure. <br /> <br /> Why Diesel? It is an engine that uses heat to run. With the added bonus that Vin Diesel can be the spokesperson.<br /> <br /> == How it works ==<br /> For each application type, there are heat templates associated for handling starting new instances to host applications and deploying application images to these instances.<br /> An application type can either be defined to be the sole tenant of an instance or define it to run in an instance along with other applications. Application isolation is achieved by docker or some sandboxing configuration depending on the environment.<br /> <br /> Users can define a new application to Diesel by choosing one of the application types. Part of the application is the URL that it will expose.<br /> When a user uploads a new version of the artifact as a Cinder image, Diesel will find an existing instance or create a new instance to host the application. The image will be deployed to the image and configuration will be run. This new running application instance will be added to the load balancer.<br /> <br /> Using Ceilometer data and heat templates, application instances will be spun up or spun down based on demand and availability constraints.<br /> <br /> == Architecture ==<br /> <br /> == Relation to other projects ==<br /> Heat - Diesel uses heat to orchestrate creating new instances, scaling instances and shutting down instances<br /> Trove - Diesel deployed applications may use trove to host their databases<br /> Solum - Solum is focused on the development lifecycle for the application. Diesel may be an environment that they deploy to.<br /> Neutron - Load Balancer Service will be used. As application instances are started and stopped they will be added and removed from load balancer</div>

Rob-raymond