Reference Guide
Table Of Contents
- 1 Introduction
- 2 Establishing Your Test and Development Environments
- 3 Developing Applications
- Introduction
- Authentication
- REST API
- Audit Logging
- Alert Logging
- Configuration
- High Availability
- OpenFlow
- Metrics Framework
- GUI
- SKI Framework - Overview
- SKI Framework - Navigation Tree
- SKI Framework - Hash Navigation
- SKI Framework - View Life-Cycle
- SKI Framework - Live Reference Application
- UI Extension
- Introduction
- Controller Teaming
- Distributed Coordination Service
- Persistence
- Backup and Restore
- Device Driver Framework
- 4 Application Security
- 5 Including Debian Packages with Applications
- 6 Sample Application
- Application Description
- Creating Application Development Workspace
- Application Generator (Automatic Workspace Creation)
- Creating Eclipse Projects
- Updating Project Dependencies
- Building the Application
- Installing the Application
- Application Code
- 7 Testing Applications
- 8 Built-In Applications
- Appendix A
- Appendix B
- Bibliography
• Controller databases
• License compliance history and metrics log data
• In a teaming environment, the teaming configuration
• User repository folder (for user-installed applications)
• Controller configuration folder
All application data that goes into the controller databases will be automatically backed up. The
applications should consider using backup and restore if they have external data that is not
already a part of the list mentioned above.
Any application that needs to backup specific data needs to register with BackupRestoreService
and implement BackupRestoreListener interface. This will ensure that the applications get a
callback to stage their backup to a specific directory provided by the BackupRestoreService. The
applications can control any data that goes into the specified directory, but the directory itself is
controlled by the backupRestoreService. The applications will not be able to create or delete the
specified directory. When the backup operation is complete, applications will get another callback
indicating a backup is complete. Once the application has staged its back up, it could wait for
backup to complete or resume its operations; this decision is implementation dependent.
Restore
The restore operation is triggered during disaster recovery. The admin uploads the backup file and
issues a REST call to restore. The restore process takes place in two steps. In the first step, the
applications themselves are restored on the controller as part of the controller restore. Once this
step is complete and the restored applications have registered with the backupRestoreService, the
second step is triggered. In the second step, the applications get a call back to restore their
specific data and state that were not a part of the controller structures listed in the previous section.
Example:
@Component
@Service
public class SampleBackupAwareApplication implements BackupRestoreListener {
@Reference(cardinality = ReferenceCardinality.MANDATORY_UNARY,
policy = ReferencePolicy.DYNAMIC)
private volatile BackupRestoreService backupRestoreService;
@Activate
protected void activate() {
backupRestoreService.register(this);
}
…
@Override
public void onBackupStart(Path directory) {
try {
// Stage application specific backup in the specified directory
112