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)
 |