cdist-backup/doc/dev/logs/2012-02-15.steven

133 lines
5 KiB
Text
Raw Normal View History

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