Toaster architecture design - Revision history

Pablo Palácios: /* bitbake/bin/toaster */

2016-08-16T19:45:23Z

bitbake/bin/toaster

← Older revision		Revision as of 19:45, 16 August 2016
Line 80:		Line 80:

	=== bitbake/bin/toaster ===		=== bitbake/bin/toaster ===
	Shell script to run if running Toaster in standalone mode on your local system this sets up Toaster's environment, loads the default config, runs the database migrations if needed and grabs the data from the [http://layers.~~openemebdded~~.org layerindex] to bootstrap Toaster, it starts the webserver and the runbuilds poller process.		Shell script to run if running Toaster in standalone mode on your local system this sets up Toaster's environment, loads the default config, runs the database migrations if needed and grabs the data from the [http://layers.openembedded.org layerindex] to bootstrap Toaster, it starts the webserver and the runbuilds poller process.

	=== toastermain/wsgi.py ===		=== toastermain/wsgi.py ===

Michael Wood: /* bldcontrol */

2016-03-30T17:34:53Z

bldcontrol

← Older revision		Revision as of 17:34, 30 March 2016
Line 67:		Line 67:

	=== bldcontrol ===		=== bldcontrol ===
	This is another Django application that is used just to utilise the Django framework rather than actually serve web pages. This module is concerned with the task of polling if there is a build scheduled via the runbuilds.py command and launching the build process, which includes commanding bitbake and doing any Git cloning / fetching layers if needed via the localhostbecontroller (we used to have multiple controller implementations), there are a number of additional tables defined to support build creation and build control specific tasks such as a BuildRequest and BuildEnvironment.		This is another Django application that is used just to utilise the Django framework rather than actually serve web pages. This module is concerned with the task of polling to see if there is a build scheduled via the runbuilds.py command and launching the build process, which includes commanding bitbake and doing any Git cloning / fetching layers if needed via the localhostbecontroller (we used to have multiple controller implementations), there are a number of additional tables defined to support build creation and build control specific tasks such as a BuildRequest and BuildEnvironment.

	=== bldcollector ===		=== bldcollector ===

Michael Wood: /* Introduction */

2016-03-30T17:30:13Z

Introduction

← Older revision		Revision as of 17:30, 30 March 2016
Line 7:		Line 7:
	Toaster is built on the Django framework, if you're not familiar with Django framework, it's very [https://docs.djangoproject.com/en/1.6/intro/tutorial01/ well documented]		Toaster is built on the Django framework, if you're not familiar with Django framework, it's very [https://docs.djangoproject.com/en/1.6/intro/tutorial01/ well documented]

	The basic layout of the framework is that for each Django application A URL defined in urls.py, ~~this~~ maps to a view defined in views.py, the urls and views have a 1:1 mapping to a function or View class in the views.py. These functions/Views runs the server side logic and ~~returns~~ data either to render a [https://docs.djangoproject.com/en/1.8/topics/templates/#the-django-template-language Django template] which can be found in the templates directory, alternatively they can return whatever http response is needed (e.g. a JSON document).		The basic layout of the framework is that for each Django application A URL defined in urls.py, maps to a view defined in views.py, the urls and views have a 1:1 mapping to a function or View class in the views.py. These functions/Views runs the server side logic and return the data either to render a [https://docs.djangoproject.com/en/1.8/topics/templates/#the-django-template-language Django template] which can be found in the templates directory or alternatively they can return whatever http response is needed (e.g. a JSON document).

	Toaster stores a lot of information about the configuration of projects, layers and recipes, this is stored in [Toaster database] which is fully abstracted via [https://docs.djangoproject.com/en/1.8/ref/models/querysets/ Django's object relation mapping (orm)]. This means that we don't have to get our hands dirty with making database connections, caring which kind of database is chosen or mapping data in and out of the database. Toaster's database schema is defined in the ''models.py'' of each of the Django applications that makes up Toaster.		Toaster stores a lot of information about the configuration of projects, layers and recipes, this is stored in [[Toaster database]] which is fully abstracted via [https://docs.djangoproject.com/en/1.8/ref/models/querysets/ Django's object relation mapping (orm)]. This means that we don't have to get our hands dirty with making database connections, caring which kind of database is chosen or mapping data in and out of the database. Toaster's database schema is defined in the ''models.py'' of each of the Django applications that makes up Toaster.

	<nowiki>		<nowiki>

Michael Wood at 17:26, 30 March 2016

2016-03-30T17:26:02Z

← Older revision		Revision as of 17:26, 30 March 2016
Line 61:		Line 61:

	=== toastergui ===		=== toastergui ===
	This is where Toaster's UI ~~and~~ related processing happens, the urls.py ,views.py are where the bulk of this is. All the web pages you see in toaster are processed via this application. As ~~toaster~~ utilises ~~Tables~~ to display information we have a special view class that deals directly with this cunningly called ToasterTables, this and a few others of our common 'widgets' can be found in widgets.py.		This is where Toaster's UI related processing happens, the urls.py ,views.py are where the bulk of this happens. All the web pages you see in toaster are processed via this application. As Toaster utilises tables to display information we have a special view class that deals directly with this, cunningly called ToasterTables, this and a few others of our common 'widgets' can be found in widgets.py.

	=== orm ===		=== orm ===
Line 84:		Line 84:
	=== toastermain/wsgi.py ===		=== toastermain/wsgi.py ===
	Django framework script that is the entry point to running the webserver as a wsgi application or as we call it [[Setting up a production instance of Toaster\|production setup]]		Django framework script that is the entry point to running the webserver as a wsgi application or as we call it [[Setting up a production instance of Toaster\|production setup]]

			== Integration with bitbake ==

	=== bitbake/lib/bb/ui/toasterui.py and buildinfohelper.py ===		=== bitbake/lib/bb/ui/toasterui.py and buildinfohelper.py ===

Michael Wood: /* Other */

2016-03-30T17:22:04Z

Other

← Older revision		Revision as of 17:22, 30 March 2016
Line 76:		Line 76:

	== Other ==		== Other ==
	- manage.py - Django framework script to manage the framework, includes commands to run unit tests, do database setup, migrations as well as running the development server process.		=== manage.py ===
	- bitbake/bin/toaster - Shell script to run if running Toaster in standalone mode on your local system this sets up Toaster's environment, loads the default config, runs the database migrations if needed and grabs the data from the [http://layers.openemebdded.org layerindex] to bootstrap Toaster, it starts the webserver and the runbuilds poller process.		Django framework script to manage the framework, includes commands to run unit tests, do database setup, migrations as well as running the development server process.
	- toastermain/wsgi.py - Django framework script that is the entry point to running the webserver as a wsgi application or as we call it [[Setting up a production instance of Toaster\|production setup]]
	- bitbake/lib/bb/ui/toasterui.py and buildinfohelper.py - These run in the bitbake observer process and are responsible for converting the events generated by bitbake by a build into objects in Toaster's database.		=== bitbake/bin/toaster ===
	- openembedded-core meta/classes/toaster.bbclass - The class that extends bitbake in order to generate build events that toaster needs (loaded via INHERIT += "toaster" )		Shell script to run if running Toaster in standalone mode on your local system this sets up Toaster's environment, loads the default config, runs the database migrations if needed and grabs the data from the [http://layers.openemebdded.org layerindex] to bootstrap Toaster, it starts the webserver and the runbuilds poller process.

			=== toastermain/wsgi.py ===
			Django framework script that is the entry point to running the webserver as a wsgi application or as we call it [[Setting up a production instance of Toaster\|production setup]]

			=== bitbake/lib/bb/ui/toasterui.py and buildinfohelper.py ===
			These run in the bitbake observer process and are responsible for converting the events generated by bitbake by a build into objects in Toaster's database.

			=== openembedded-core meta/classes/toaster.bbclass ===
			The class that extends bitbake in order to generate build events that toaster needs (loaded via INHERIT += "toaster" )

Michael Wood: /* Other */

2016-03-30T17:21:03Z

Other

← Older revision		Revision as of 17:21, 30 March 2016
Line 76:		Line 76:

	== Other ==		== Other ==
	- manage.py - Django framework script to manage the framework, includes commands to run unit tests, do database setup, migrations as well as running the development server process.		- manage.py - Django framework script to manage the framework, includes commands to run unit tests, do database setup, migrations as well as running the development server process.
	- bitbake/bin/toaster - Shell script to run if running Toaster in standalone mode on your local system this sets up Toaster's environment, loads the default config, runs the database migrations if needed and grabs the data from the [http://layers.openemebdded.org layerindex] to bootstrap Toaster, it starts the webserver and the runbuilds poller process.		- bitbake/bin/toaster - Shell script to run if running Toaster in standalone mode on your local system this sets up Toaster's environment, loads the default config, runs the database migrations if needed and grabs the data from the [http://layers.openemebdded.org layerindex] to bootstrap Toaster, it starts the webserver and the runbuilds poller process.
	- toastermain/wsgi.py - Django framework script that is the entry point to running the webserver as a wsgi application or as we call it [[Setting up a production instance of Toaster\|production setup]]		- toastermain/wsgi.py - Django framework script that is the entry point to running the webserver as a wsgi application or as we call it [[Setting up a production instance of Toaster\|production setup]]
			- bitbake/lib/bb/ui/toasterui.py and buildinfohelper.py - These run in the bitbake observer process and are responsible for converting the events generated by bitbake by a build into objects in Toaster's database.
			- openembedded-core meta/classes/toaster.bbclass - The class that extends bitbake in order to generate build events that toaster needs (loaded via INHERIT += "toaster" )

Michael Wood at 17:12, 30 March 2016

2016-03-30T17:12:23Z

@@ Line 1: / Line 1: @@
 [[Category:Toaster]]
 Toaster project is located in [http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/bitbake/lib/toaster/ bitbake/lib/toaster].
@@ Line 9: / Line 11: @@
 Toaster stores a lot of information about the configuration of projects, layers and recipes, this is stored in [Toaster database] which is fully abstracted via [https://docs.djangoproject.com/en/1.8/ref/models/querysets/ Django's object relation mapping (orm)]. This means that we don't have to get our hands dirty with making database connections, caring which kind of database is chosen or mapping data in and out of the database. Toaster's database schema is defined in the ''models.py'' of each of the Django applications that makes up Toaster.
 == Toaster's Django applications ==
@@ Line 27: / Line 75: @@
 This is the overarching/main Django application which loads the 4 above. It is where the default [https://docs.djangoproject.com/en/1.8/ref/settings/ settings] for Toaster are.
-=== Other ===
+== Other ==
   - manage.py  - Django framework script to manage the framework, includes commands to run unit tests, do database setup, migrations as well as running the development server process.
   - bitbake/bin/toaster - Shell script to run if running Toaster in standalone mode on your local system this sets up Toaster's environment, loads the default config, runs the database migrations if needed and grabs the data from the [http://layers.openemebdded.org layerindex] to bootstrap Toaster, it starts the webserver and the runbuilds poller process.
   - toastermain/wsgi.py - Django framework script that is the entry point to running the webserver as a wsgi application or as we call it [[Setting up a production instance of Toaster|production setup]]

Michael Wood at 17:01, 30 March 2016

2016-03-30T17:01:32Z

@@ Line 1: / Line 1: @@
 [[Category:Toaster]]
-[[Toaster]] is designed as a collection of components that will run independently performing isolated functions. The interfaces between components are documented on this wiki as to ease interoperability with newer components. From design phase, we've taken care to account for further expansion needs, and account for scalability problems.
+Toaster project is located in [http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/bitbake/lib/toaster/ bitbake/lib/toaster].
-* [[ Django models ]]
+Toaster is built on the Django framework, if you're not familiar with Django framework, it's very [https://docs.djangoproject.com/en/1.6/intro/tutorial01/ well documented]
-* [[ REST API Contracts ]]
+The basic layout of the framework is that for each Django application A URL defined in urls.py, this maps to a view defined in views.py, the urls and views have a 1:1 mapping to a function or View class in the views.py. These functions/Views runs the server side logic and returns data either to render a [https://docs.djangoproject.com/en/1.8/topics/templates/#the-django-template-language Django template] which can be found in the templates directory, alternatively they can return whatever http response is needed (e.g. a JSON document).
-* [[Bugzilla feature list]]
+Toaster stores a lot of information about the configuration of projects, layers and recipes, this is stored in [Toaster database] which is fully abstracted via [https://docs.djangoproject.com/en/1.8/ref/models/querysets/ Django's object relation mapping (orm)]. This means that we don't have to get our hands dirty with making database connections, caring which kind of database is chosen or mapping data in and out of the database. Toaster's database schema is defined in the ''models.py'' of each of the Django applications that makes up Toaster.

Michael Wood at 10:17, 15 October 2015

2015-10-15T10:17:08Z

← Older revision		Revision as of 10:17, 15 October 2015
Line 5:		Line 5:

	[[Toaster]] is designed as a collection of components that will run independently performing isolated functions. The interfaces between components are documented on this wiki as to ease interoperability with newer components. From design phase, we've taken care to account for further expansion needs, and account for scalability problems.		[[Toaster]] is designed as a collection of components that will run independently performing isolated functions. The interfaces between components are documented on this wiki as to ease interoperability with newer components. From design phase, we've taken care to account for further expansion needs, and account for scalability problems.

	* [[ Data store investigation results and choices ]]

	* [[ Django models ]]		* [[ Django models ]]

Belenbarrospena at 15:47, 16 May 2014

2014-05-16T15:47:02Z

← Older revision		Revision as of 15:47, 16 May 2014
Line 1:		Line 1:
			[[Category:Toaster]]
	We are planning the capabilities of [[Toaster]] based on evolutive stages of implementation, using community feedback on each stage to plan, design and implement a set of capabilities for the next stage.		We are planning the capabilities of [[Toaster]] based on evolutive stages of implementation, using community feedback on each stage to plan, design and implement a set of capabilities for the next stage.
	In the first stage, synchronized with the planning of [https://www.yoctoproject.org/download/toaster-web-interface Yocto Project 1.5 release], we implemented the back end of a build analysis / image inspection module.		In the first stage, synchronized with the planning of [https://www.yoctoproject.org/download/toaster-web-interface Yocto Project 1.5 release], we implemented the back end of a build analysis / image inspection module.