Solum-du-creation
Problem:
A deployment unit (DU) is the artifact made up of the built application code along with its runtime environment. Within a DU, a 'language pack' provides the build and runtime environment for the application code. Solum will provide different language packs for different supported languages. A running instance of an application is created when a DU is 'deployed'.
This BP considers creation of a DU.
Requirements:
As part of DU creation, we want to:
- detect the language pack to be used (for M1, we are going to specify the language pack to be used)
- run any application specific unit tests if they are provided (for M1, we are not targeting this requirement)
- upload the DU to glance
Proposed Solution:
In order to create a DU, we propose that Solum provide a 'build service' which supports two things. First, a generic format to specify things such as the language pack to be used, location of the application code on the DU, specification of any configuration variables to be provided to the application at runtime, and so on. Second, a generic mechanism to trigger the DU creation steps. The trigger mechanism of this service is essentially its interface to the other parts of the system. The purpose of doing this is so that the service can be situated at different stages of the Solum workflow if so desired.
One of things that we need as part of a DU creation is the specification of a language pack to be used to create it.
For that, we need to be able to query the list of currently registered language packs in Solum. This requirement is addressed by the following BP:
https:/
Blueprint information
- Status:
- Complete
- Approver:
- Adrian Otto
- Priority:
- Undefined
- Drafter:
- Devdatta Kulkarni
- Direction:
- Needs approval
- Assignee:
- None
- Definition:
- Obsolete
- Series goal:
- None
- Implementation:
-
Unknown
- Milestone target:
- None
- Started by
- Completed by
- Adrian Otto
Related branches
Related bugs
Sprints
Whiteboard
(Devdatta) - Following questions came up about the build service after a recent chat with Angus .
Should we use Jenkins to perform DU creation? The high-level idea is to decouple image_handler from the steps of image creation. The handler will send a message to a 'system', which can be either a custom designed build service, or one or more Jenkins slaves which will perform the task of image creation.
What are the concerns with this approach?
(Paul Cz) - I think Jenkins is a suitable tool for integrating with solum to perform builds, however it should be loosely coupled and we should provide a basic build mechanism that will allow us to test end-to-end inside a single host devstack ( jenkins will be heavy and slow in that scenario ).
Solum-API -> Oslo Message -> Solum Build Dispatcher -> Build Script -> Solum API
Solum-API -> Oslo Message -> Solum Build Dispatcher -> Jenkins -> Solum API
My concerns with running Jenkins by default is mostly around performance for solum developers/testing ( devstack is already heavy enough ) and/or potential issues with incubation by requiring a hard to manage/run Java app.
(Paul Cz) - upload to glance... If we go with the current incarnation of the docker nova driver we could start a registry per user ( when you start the registry you provide glance credentials ) we would then need to make the docker driver multi-registry aware and have some sort of mapping between tenantid and docker registry URI.
