From bb44f1573a9088fecbaccec8523bf641129b3970 Mon Sep 17 00:00:00 2001 From: Narayan Desai Date: Tue, 18 Oct 2005 23:00:21 +0000 Subject: Delete: doc/service-model }(Logical change 1.340) git-svn-id: https://svn.mcs.anl.gov/repos/bcfg/trunk/bcfg2@1401 ce84e21b-d406-0410-9b95-82705330c041 --- doc/service-model | 26 -------------------------- 1 file changed, 26 deletions(-) delete mode 100644 doc/service-model diff --git a/doc/service-model b/doc/service-model deleted file mode 100644 index 26d628cb3..000000000 --- a/doc/service-model +++ /dev/null @@ -1,26 +0,0 @@ -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