forked from ungleich-public/cdist
		
	
		
			
				
	
	
		
			132 lines
		
	
	
	
		
			5 KiB
		
	
	
	
		
			Text
		
	
	
	
	
	
			
		
		
	
	
			132 lines
		
	
	
	
		
			5 KiB
		
	
	
	
		
			Text
		
	
	
	
	
	
| - parameter/setting default from manifest
 | |
|     ==> BRANCH[feature_default_parameters],
 | |
|     ==> PERSON[Steven or Nico]
 | |
|     ==> PROPOSAL(1)
 | |
|     - current bug
 | |
|     - proposal 1: parameter/default/$name (for optional ones)
 | |
|         - new way
 | |
|         - catches --state absent|present
 | |
|         - needs changes of types
 | |
|         - also possible for explorer
 | |
|         - support for it in core?
 | |
|             - handling of ${o} $o "$o" ?
 | |
|             - handling which variables?
 | |
|             - introduction of "templating language"
 | |
|                 - aka macros
 | |
|                 - possible problems:
 | |
|                     - inconsistency
 | |
|                     - redoing shell functionality
 | |
|                     - raising expectations for more templating from users
 | |
|                 - possible benefit
 | |
|                     - no need for eval
 | |
|                     - once in core, not everytime in type
 | |
|                         - OTOH: one extra word. 
 | |
|                         - a=$(cat $__object/parameter/name) vs. $(eval $(cat $__object/parameter/name))
 | |
|         - only possible for static defaults
 | |
|             - --name overrides name not possible vs. object_id
 | |
|                 - Is this the only case????
 | |
|                     - if yes: don't care.
 | |
|                 - possible solution:
 | |
|                     - echo '/$__object_id' > typename/parameter/default/name
 | |
|                     - eval $(cat $__object/parameter/name)
 | |
|                         - probably allows code injection
 | |
|                             - is possible anyway???
 | |
|                             - $(cat /etc/shadow)
 | |
|                         - other eval side effects???
 | |
|                             - none: go for it
 | |
|                             - some: have headache
 | |
|                             - many: don't do
 | |
|     - proposal 2: 2 dbs (user input vs. stuff changable by type)
 | |
|         - explicit 2nd db [parameter_user and parameter/]
 | |
|         - not very clean (both agreed)
 | |
|     - proposal 3: parameter are read-only
 | |
|         - breaks current types (in core probably elsewhere)
 | |
|         - can't enforce, but user is on his own => breaks, her problem
 | |
|         + clean seperation between core and type (nico)
 | |
|             - parameter belongs to type not core (steven)
 | |
|     - proposal 4: core ignores changes in parameter/* of object
 | |
|         - implicit 2nd db [see automagic below]
 | |
|         - steven+++
 | |
|         - does not work with divergent emulator not being in core
 | |
|             - because emulators primary db __is__ fs.
 | |
| 
 | |
| 1 manifest:
 | |
| 
 | |
| __foo bar == emulator
 | |
| echo present > $__global/object/__foo/bar/parameter/state
 | |
| 
 | |
| # fails
 | |
| __foo bar == emulator
 | |
| 
 | |
| ! automagic / filesystem
 | |
|     ! fsproperty:
 | |
|         - kill, write explicitly to disk
 | |
|     ==> BRANCH[cleanup_fsproperty]
 | |
|     ==> PERSON[Steven]
 | |
|     ==> PROPOSAL(just cleanup)
 | |
| 
 | |
|     - implicit/automatic writes/read to fs
 | |
|         - explicit interfaces are better then implicit
 | |
|         - same problems as in cdist 1.x to 2.x move! (environment!)
 | |
|     - format on disk should not change/dictate code flow
 | |
|         - degrade python to shell (nico++! steven--)
 | |
|             - user should not care about python, ruby, .net or ASM implementation (steven++ nico++)
 | |
| 
 | |
|     ? proposal 1: diverge emulator / core
 | |
|         - emulator verifies input
 | |
|         - emulator writes to fs
 | |
|         - core reads/syncs from/to fs before passing control to user
 | |
| 
 | |
|     ? proposal 2: emulator is dumb and passes data to core
 | |
|         - core creates objects
 | |
|         - no fs involved
 | |
|         - core reads/syncs from/to fs before passing control to user
 | |
|         - passing:
 | |
|             - full objects via pickle
 | |
|             - parameters only
 | |
|             - how???
 | |
|                 - unix socket?
 | |
|                     - not everywhere possible?
 | |
|                 - tcp / ip
 | |
|                     - not everywhere possible
 | |
|                         - chroot / local only
 | |
|                 - rfc 1149
 | |
|                     - not everywhere possible
 | |
|                         - missing avian carriers
 | |
|                 - 0mq
 | |
|                     - not everywhere possible
 | |
|                         - not installed
 | |
|                 - shm (ipcs and friends)
 | |
|                     - not everywhere possible
 | |
|                         - no /dev/shm, different libraries? cleanups needed...
 | |
|                 - what speaks against FS?
 | |
|                     - emulator_input/.../
 | |
| 
 | |
|                 - nico: to fancy probably
 | |
| 
 | |
| ! boolean implementation
 | |
|     ==> BRANCH[feature_boolean_parameter]
 | |
|     ==> PERSON[Steven]
 | |
|     - nico: 
 | |
|         - parameters/boolean: document
 | |
|         - argparse changes (consider parameters/boolean)
 | |
|             - create 
 | |
|     - can be implemented with changes in emulator
 | |
|         - use store_true, del if false => never seen by core
 | |
|     - INDEPENDENT INDEPENDT OF FS.PROPERTIES!!111111!
 | |
| 
 | |
| - emulator:
 | |
|     - how much integrated into core
 | |
|         - also: using CdistObject????
 | |
|     - dependency on filesystem: good (nico) | bad (steven)
 | |
| 
 | |
| - singleton / support without object_id
 | |
|     - not discussed
 | |
| 
 | |
| - __apt_ppa:
 | |
|     ==> BRANCH[bugfix_do_not_change_state_in_manifest]
 | |
|     ==> PERSON[Nico]
 | |
| 
 | |
| - logging divergent between emulator / core
 | |
|     - no problem (nico)
 | |
|     - may be helpful (steven)
 |