On Thu, 2009-03-05 at 15:04 -0800, Erik Nordmark wrote: > Do we know how long time it might take for that to gel?
I think it's however long we want it to take. It requires us putting our heads together and working out the details. > If it takes long, would it be useful to consider SCF as just a > repository and not worrying about how things are split into multiple > instances, or does that just make it more complex? > > The reason I'm asking is that we appear to have an immediate problem (or > problems) relating to the repository, thus using SCF in a "flat" way > might potentially help. By this I mean a single service > (physical:default or datalink-management:default) would have a bunch of > properties whose names are based on the ifname/datalink name. We actually proposed to do this in the early stages of the Clearview design. The datalink-management service was going to have one property group per datalink, with link configuration currently in datalink.conf represented as properties within each group. Dan Groves actually went as far as implementing this, and it worked quite well. During design review, discussions with various folks resulted in our backing off of this plan and going back to a flat file. The reason was because this approach didn't appear to be making progress toward (and was believed to be counter to) a perceived ultimate goal of representing each interface as a service, and placing each interface's configuration within each instance's properties. It was also deemed to be using SMF as a configuration dumping ground. That said, this was years ago, and perhaps some of the operational experience with Fishworks may break down a bit of the ideology surrounding SMF and give projects more flexibility with how they practically can use it. I think it would be good to get the group together to talk about what Fishworks has learned from this model. -Seb
