-
Notifications
You must be signed in to change notification settings - Fork 6
Technical Cabal 4th Dec 2012
mtaylor edited this page Jan 15, 2013
·
1 revision
Attendees (please add your name here)
- Martyn Taylor
- jayg
- Ian McLeod
- Scott Seago
- Greg Blomquist
- Eric Helms
- Eck
- morazi
- Tomas Sedovic
Sorry, no recording this week.
Procedural
- Write up mintues in wiki?
- Put minutes in Github wiki
- Format?
- Conference call
- Agenda?
- Put on Wiki
Tech Topics
- API State Discussion - Martyn and Scott
- Notes
- Any service level components, e.g. dbomatic, monitoring instance state would use a different API than the client API
- Tech cabal in agreement with plan
- State changes will be represented as PUT attributes
- Unresolved question: do we want to handle this extra edit level with permissions?
- Action:
- Martyn write up proposal
- Notes
- Image Versioning
- Notes:
- Support a high-level set of image instance in the deployables in Conductor
- Two different versions of the same base image are different
- Discussions were held to determine how to handle template versions for each image version or within a base image don't allow template updates, but allow versioning and updates in the templates themselves
- Higher level construct vs multiple base images per template
- Container object that contains multiple base object builds
- Base image in conductor is already versioned and connected to the same base image object
- Factory doesn't need to collect related builds and put them together, Conductor does
- Outstanding:
- Issue: Need a way to version templates as they are modified over time
- Is there a need for associating a collection of related templates?
- If you have some notion of a collection of immutable templates, how does that interact with base images?
- Unresolved: interaction between master template and template versions
- Action:
- 3-5 user stories to drive Conductor, and write the design to address the stories
- Notes: