From 81c9ecc82c149e22d58930d8b339ad8d0cc2cd93 Mon Sep 17 00:00:00 2001 From: Narayan Desai Date: Mon, 1 Mar 2004 22:19:11 +0000 Subject: (Logical change 1.18) git-svn-id: https://svn.mcs.anl.gov/repos/bcfg/trunk/bcfg2@69 ce84e21b-d406-0410-9b95-82705330c041 --- doc/service-model | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+) (limited to 'doc/service-model') diff --git a/doc/service-model b/doc/service-model index e69de29bb..26d628cb3 100644 --- a/doc/service-model +++ b/doc/service-model @@ -0,0 +1,26 @@ +One of the more grungy and fragile portions of the bcfg1 configuration +description interface is that of bundle allocation. To wit, tags are +used for two purposes in this same process. The first use is for +initial choice of the software complement for any particular node. The +second use is for specialization of particular nodes. The use of a tag +for either purpose isn't particularly discernible from the other, +moreover, tags can be used for multiple purposes simultaneously. + + + + + + +There is a whole lot going on here, so i will highlight the +particulars i think are important. +1. There is explicit linkage between a service and the software that + provides it. +2. there is an explicit scope to describe "how far" the service goes +3. there is a notion of what network transport is required. +4. you can construct monitoring/firewalling rules from this +5. you can infer failure cascades from the relationship +6. tags are used in choosing configurations as a specialization + mechanism, no just through bundles. + +How do we extend the idea of coherence from bcfg1? \ No newline at end of file -- cgit v1.2.3-1-g7c22