I don't want to change it but as some bundles are already provided in this file and installed, it is important to report somewhere such information in case of recovery after a server update, ...
On Thu, Apr 2, 2009 at 4:50 PM, Guillaume Nodet <[email protected]> wrote: > I think in all cases, if you want to manage a cluster of kernels, > using the deploy folder is not necesseraly the best idea. Or just use > rsync to copy over the changes then ... But having a full back up > requires much more than that, it would need the preference services, > the config admin, and all other configuration files in the /etc > folder. > Btw, what's your use case for changing the startup.properties file ? > > On Thu, Apr 2, 2009 at 16:45, Charles Moulliard <[email protected]> > wrote: > > Using features list as the installation contract is a good idea but in > this > > case, the deploy folder must be forbidden otherwise we will have a gap > > between the content of the list + what is installed using deploy folder > > > > In resume : startup.properties + features list + folder deploy = list of > > bundles to be backuped > > > > > > > > On Thu, Apr 2, 2009 at 4:27 PM, Guillaume Nodet <[email protected]> > wrote: > > > >> On Thu, Apr 2, 2009 at 16:23, Jamie G. <[email protected]> > wrote: > >> > 1) Backup/recover config files > >> > > >> > Interesting, would be a useful feature. > >> > > >> > 2) Log rotation (already discussed) > >> > > >> > 3) Image of bundles installed.. > >> > > >> > This sounds very useful to me, kind of like taking a system snapshot > >> > that an administrator could roll back to if need be (great when dozens > >> > of bundles are involved). Would this be another web admin interface > >> > delivered feature or something we would do via the kernel shell > >> > interface? I would assume the shell would be the best place for this > >> > type of administrative function. > >> > >> I see a web console as offering the same features than the shell, so > >> imho, everything available from the web should be available from the > >> lower level shell also. > >> > >> What about building the rollback into the features service ? So that > >> if the installation fails, it would leave the runtime in the same > >> state that it was before installing the bundles. If everything is > >> define by a feature, the state would only be the list of installed > >> feature which may be way easier to manage. > >> > >> > > >> > On Thu, Apr 2, 2009 at 11:05 AM, Charles Moulliard < > [email protected]> > >> wrote: > >> >> Concerning the backup strategy, I see two points : > >> >> > >> >> 1) Backup/recover config files > >> >> > >> >> This can be achieved through web admin interface. A zip file will be > >> >> generated containing the config files and named according to the > current > >> >> system date. In case of trouble (after parameter modification or > >> >> reinstallation), the user can reinstall files > >> >> > >> >> 2) Log rotation (already discussed) : can be defined in the existing > cfg > >> >> file > >> >> > >> >> 3) Keep image of the bundles installed (useful to roll back install > of > >> >> project = sum of bundles) > >> >> With this feature, the deployer can be roll back an installation in > case > >> of > >> >> problem > >> >> > >> >> Charles > >> >> > >> >> > >> >> On Thu, Apr 2, 2009 at 3:16 PM, Jamie G. <[email protected]> > >> wrote: > >> >> > >> >>> I'd like to know more about the Backup strategy too. Are we looking > >> >>> for some best practices documentation or something more > comprehensive > >> >>> (such as disaster recovery scenario)? > >> >>> > >> >>> We already have some fail over support via the kernel as Guillaume > has > >> >>> noted. > >> >>> > >> >>> Cheers, > >> >>> Jamie > >> >>> > >> >>> >> - Backup strategy, > >> >>> > > >> >>> > Please explain ? Is this related to > >> >>> > > >> >>> > >> > http://servicemix.apache.org/kernel/67-configuring-failover-deployments-available-in-110.html > >> >>> > ? > >> >>> > >> >> > >> > > >> > >> > >> > >> -- > >> Cheers, > >> Guillaume Nodet > >> ------------------------ > >> Blog: http://gnodet.blogspot.com/ > >> ------------------------ > >> Open Source SOA > >> http://fusesource.com > >> > > > > > > -- > Cheers, > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ > ------------------------ > Open Source SOA > http://fusesource.com >
