Dynamic installation and activation of software packages in a distributed networking device

• US 7,461,374 B1
• Filed: 12/01/2003
• Issued: 12/02/2008
• Est. Priority Date: 12/01/2003
• Status: Active Grant

• Current Assignee: Cisco Technology, Inc. (Cisco Systems, Inc.)
• Original Assignee: Cisco Technology, Inc. (Cisco Systems, Inc.)
• Inventors: Balint, Matthew, Darling, Glen, Wooff, Douglas, Fitzgerald, John
• Primary Examiner(s): Kiss; Eric B
• Assistant Examiner(s): Wang; Ben C
• Application Number:
  US10/726,067
• Time in Patent Office: 1,828 Days
• Field of Search: None
• US Class Current: 717/174
• CPC Class Codes: G06F 8/658 Incremental updates; Differential updates

Abstract

A method for dynamic installation and activation of software packages in a distributed networking device. A master node provides a software package database that contains software packages for all nodes. It notifies a node that a software update is being requested, which examines the package identifiers and the dependencies and determines the running processes that will be affected by the update. The processes evaluate the effect that the update will have on their operation. If any of the processes determine that the update will degrade or have a negative impact on the operation of the node, the process will veto the update. If the master node receives no vetoes, it updates the node which installs and activates without interrupting the normal operation of the node.

Claims

1. A method of dynamic installation and activation of software packages in a node in a distributed network of nodes, the method comprising the computer-implemented steps of:

storing, in a software package storage of a master node in the distributed network, a plurality of software packages and a plurality of software modules that the nodes in the distributed network will be using;

wherein each software package of the plurality of software packages contains at least one module and associated dependency information;

receiving a software update for a node on said master node;

wherein the software update contains a set of one or more software packages;

storing the software update on said software package storage;

wherein said master node notifies said node that a software update is being requested;

wherein said master node passes said node identities of one or more software packages to be updated and module dependencies;

wherein said node determines, using the module dependencies and before installing the software update, running processes on said node that will be affected by the software update.

2. A method as recited in claim 1, wherein each module has a binary signature.

3. A method as recited in claim 1, wherein each node has a list of desired characteristics stored on said master node which is compared by said master node to each module in the software update to determine which modules in the set of one or more software packages should be sent to a node.

4. A method as recited in claim 1, wherein said node notifies affected processes that the software update is being requested;

wherein each notified process evaluates the effect that the software update will have on its operation;

wherein if any of the notified processes determine that the software update will degrade or have a negative impact on said node'"'"'s normal operation, the process returns a veto to said node; and

wherein if a process finds that the software update will have no negative effects, the process returns an acceptance of the software update to said node.

5. A method as recited in claim 4, wherein said node waits for all of the notified processes to return results of their evaluations and once all of the processes have reported to said node, said node notifies said master node if any of the processes have vetoed the software update.

6. A method as recited in claim 5, wherein if said master node receives an acceptance from said node then said master node sends the set of one or more software packages from said software package storage to said node.

7. A method as recited in claim 6, wherein said node immediately runs software package modules, by loading the modules from the software package(s) and signals processes that are being replaced by the modules and the affected processes that the changeover is going to occur;

wherein when all of the signaled processes indicate that they are ready and waiting for the changeover, said node starts new modules and signals the affected processes that the changeover has occurred;

wherein each module starts without affecting normal operation of said node; and

wherein each affected process restarts, if required, without affecting normal operation of said node.

8. A method as recited in claim 7, wherein said node continues with normal operations and notifies said master node that it has completed the software update;

and wherein said master node checks the module dependencies to ensure that any inter-nodal and intra-node dependencies are complete.

9. A method as recited in claim 8, wherein if there are any discrepancies in the inter-nodal and intra-node dependencies, then said master node notifies a user.

10. A method as recited in claim 7, further comprising storing, in the software package storage, older versions of the software packages and the software modules that are kept for regressing said node back to a previous module or software package version, wherein when said node does not store the set of one or more software packages in its local persistent storage, then said node can later regress back to previous modules stored in the local persistent storage if it restarts or said master node tells it to regress.

11. A method as recited in claim 6, wherein said node extracts version information and dependency information from the set of one or more software packages and stores the information in its local persistent storage.

12. A method as recited in claim 11, wherein said node compares binary signatures of modules in the set of one or more software packages with corresponding modules stored in the local persistent storage to discover which modules have been updated;

wherein any binary signatures that match indicate that the module has not changed; and

wherein any modules that have different binary signatures replace the corresponding modules stored in the local persistent storage.

13. A method as recited in claim 12, wherein said node runs software package modules by loading the modules from the set of one or more software packages and signals processes that are being replaced by the modules and the affected processes that a changeover is going to occur;

wherein when all of the signaled processes indicate that they are ready and waiting for the changeover, the node starts new modules and signals the affected processes that the changeover has occurred;

wherein each module starts without affecting normal operation of said node; and

wherein each affected process restarts, if required, without affecting normal operation of said node.

14. A method as recited in claim 13, wherein said node continues with normal operations and notifies said master node that it has completed the software update;

and wherein said master node checks dependencies of the set of one or more software packages to ensure that any inter-nodal and intra-node dependencies are complete.

15. A method as recited in claim 14, wherein if there are any discrepancies in the inter-nodal and intra-node dependencies, then said master node notifies a user.

16. A method as recited in claim 5, wherein if more than one node was being updated, the software update will not occur if any node vetoes the software update.

17. A method as recited in claim 5, wherein if said master node receives a veto from said node, then said master node does not update said node and notifies a user that the software update will adversely affect said node.

18. A method as recited in claim 17, further comprising receiving an indication to continue updating said node, wherein said master node forces said node to accept the software update.

19. A method as recited in claim 1, further comprising initiating the software update by receiving an image containing the software update onto said master node.

20. A method as recited in claim 19, receiving an indication of a set of nodes and a set of software packages that are to be updated.

21. A method as recited in claim 1, wherein the software update contains a list of nodes to be updated.

22. A method as recited in claim 1, wherein the software update contains a list of software packages destined for each node.

23. A method as recited in claim 1, wherein the master node has an ability to categorize nodes into classes where all of the nodes in a particular class of nodes have a same software configuration and may have differing processor types.

24. A method as recited in claim 1, wherein each software package of the plurality of software packages contains version information, dependency information, and other metadata information pertaining to software in the package.

25. A method as recited in claim 24, wherein the other metadata information includes a list of application program interface (API) providers and consumers.

26. A computer-readable storage medium carrying one or more sequences of instructions for dynamic installation and activation of software packages in a node in a distributed network of nodes, which instructions, when executed by one or more processors, cause the one or more processors to carry out the steps of:

storing, in a software package storage of a master node in the distributed network, a plurality of software packages and a plurality of software modules that the nodes in the distributed network will be using;

wherein each software package of the plurality of software packages contains at least one module;

receiving a software update for a node on said master node;

wherein the software update contains a set of one or more software packages;

storing the software update on said software package storage;

wherein said master node notifies said node that a software update is being requested;

wherein said master node passes said node identities of one or more software packages to be updated and module dependencies; and

wherein said node determines, using the module dependencies and before installing the software update, running processes on said node that will be affected by the software update.

27. A computer-readable storage medium as recited in claim 26, wherein each module has a binary signature.

28. A computer-readable storage medium as recited in claim 26, wherein each node has a list of desired characteristics stored on said master node which is compared by said master node to each module in the software update to determine which subset of modules should be sent to a node.

29. A computer-readable storage medium as recited in claim 26, wherein said node notifies affected processes that the software update is being requested;

wherein each notified process evaluates the effect that the software update will have on its operation;

wherein if any of the notified processes determine that the software update will degrade or have a negative impact on said node'"'"'s normal operation, the process returns a veto to said node; and

wherein if a process finds that the software update will have no negative effects, the process returns an acceptance of the software update to said node.

30. A computer-readable storage medium as recited in claim 29, wherein said node waits for all of the notified processes to return results of their evaluations and once all of the processes have reported to said node, said node notifies said master node if any of the processes have vetoed the software update.

31. A computer-readable storage medium as recited in claim 30, wherein if said master node receives an acceptance from said node then said master node sends the set of one or more software packages from said software package storage to said node.

32. A computer-readable storage medium as recited in claim 31, wherein said node immediately runs software package modules, by loading the modules from the software package(s) and signals processes that are being replaced by the modules and the affected processes that the changeover is going to occur;

wherein when all of the signaled processes indicate that they are ready and waiting for the changeover, the node starts new modules and signals the affected processes that the changeover has occurred;

wherein each module starts without affecting normal operation of said node; and

wherein each affected process restarts, if required, without affecting normal operation of said node.

33. A computer-readable storage medium as recited in claim 32, wherein said node continues with normal operations and notifies said master node that it has completed the software update;

and wherein said master node checks the module dependencies to ensure that any inter-nodal and intra-node dependencies are complete.

34. A computer-readable storage medium as recited in claim 33, wherein if there are any discrepancies in the inter-nodal and intra-node dependencies, then said master node notifies a user.

35. A computer-readable storage medium as recited in claim 32, wherein the sequences of instructions include instructions which, when executed by the one or more processors, further cause the one or more processors to perform storing, in the software package storage, older versions of a subset of the plurality of software packages and a subset of the plurality of software modules that are kept for regressing said node back to a previous software module or software package version, wherein when said node does not store the set of one or more software packages in its local persistent storage, then said node can later regress back to previous modules stored in the local persistent storage if it restarts or said master node tells it to regress.

36. A computer-readable storage medium as recited in claim 31, wherein said node extracts version information and dependency information from the set of one or more software packages and stores the information in its local persistent storage.

37. A computer-readable storage medium as recited in claim 36, wherein said node compares binary signatures of modules in the set of one or more software packages with corresponding modules stored in the local persistent storage to discover which modules have been updated;

wherein any binary signatures that match indicate that the module has not changed; and

wherein any modules that have different binary signatures replace the corresponding modules stored in the local persistent storage.

38. A computer-readable storage medium as recited in claim 37, wherein said node runs software package modules by loading the modules from the set of one or more software packages and signals processes that are being replaced by the modules and the affected processes that a changeover is going to occur;

wherein when all of the signaled processes indicate that they are ready and waiting for the changeover, the node starts new modules and signals the affected processes that the changeover has occurred;

wherein each module starts without affecting normal operation of said node; and

wherein each affected process restarts, if required, without affecting normal operation of said node.

39. A computer-readable storage medium as recited in claim 38, wherein said node continues with normal operations and notifies said master node that it has completed the software update;

and wherein said master node checks dependencies of the set of one or more software packages to ensure that any inter-nodal and intra-node dependencies are complete.

40. A computer-readable storage medium as recited in claim 39, wherein if there are any discrepancies in the inter-nodal and intra-node dependencies, then said master node notifies a user.

41. A computer-readable storage medium as recited in claim 30, wherein if more than one node was being updated, the software update will not occur if any node vetoes the software update.

42. A computer-readable storage medium as recited in claim 30, wherein if said master node receives a veto from said node, then said master node does not update said node and notifies a user that the software update will adversely affect said node.

43. A computer-readable storage medium as recited in claim 42, wherein the instructions include instructions which, when executed by the one or more processors, further cause the one or more processors perform receiving an indication to continue updating said node, wherein said master node forces said node to accept the software update.

44. A computer-readable storage medium as recited in claim 26, wherein the one or more sequences of instructions are instructions which, when executed by the one or more processors, further cause the one or more processors to perform initiating the software update by receiving an image containing the software update onto said master node.

45. A computer-readable storage medium as recited in claim 44, wherein the one or more sequences of instructions are instructions which, when executed by the one or more processors, further cause the one or more processors to perform the step of receiving an indication of a set of nodes and a set of software packages that are to be updated.

46. A computer-readable storage medium as recited in claim 26, wherein the software update contains a list of nodes to be updated.

47. A computer-readable storage medium as recited in claim 26, wherein the software update contains a list of software packages destined for each node.

48. A computer-readable storage medium as recited in claim 26, wherein the master node has an ability to categorize nodes into classes where all of the nodes in a particular class of nodes have a same software configuration and may have differing processor types.

49. A computer-readable storage medium as recited in claim 26, wherein each software package of the plurality of software packages contains version information, dependency information, and other metadata information pertaining to software in the package.

50. A computer-readable storage medium as recited in claim 49, wherein the other metadata information includes a list of application program interface (API) providers and consumers.

51. An apparatus, comprising:

a master node;

means for storing, in a software package storage of the master node, a plurality of software packages and a plurality of software modules that nodes in a distributed network will be using;

wherein each software package of the plurality of software packages contains at least one module;

means for receiving a software update for a node on said master node;

wherein the software update contains a set of one or more software packages;

means for storing the software update on said software package storage;

wherein said master node notifies said node that a software update is being requested;

wherein said master node passes said node identities of one or more software packages to be updated and module dependencies; and

wherein said node determines, using the module dependencies and before installing the software update, running processes on said node that will be affected by the software update.

52. An apparatus as recited in claim 51, wherein each module has a binary signature.

53. An apparatus as recited in claim 51, wherein each node has a list of desired characteristics stored on said master node which is compared by said master node to each module in the software update to determine which subset of modules should be sent to a node.

54. An apparatus as recited in claim 51, wherein said node notifies affected processes that the software update is being requested;

wherein each notified process evaluates the effect that the software update will have on its operation;

wherein if any of the processes determine that the software update will degrade or have a negative impact on said node'"'"'s normal operation, the process returns a veto to said node; and

wherein if a process finds that the software update will have no negative effects, the process returns an acceptance of the software update to said node.

55. An apparatus as recited in claim 54, wherein said node waits for all of the notified processes to return results of their evaluations and once all of the processes have reported to said node, said node notifies said master node if any of the processes have vetoed the software update.

56. An apparatus as recited in claim 55, wherein if said master node receives an acceptance from said node then said master node sends the set of one or more software packages from said software package storage to said node.

57. An apparatus as recited in claim 56, wherein said node immediately runs software package modules, by loading the modules from the software package(s) and signals processes that are being replaced by the modules and the affected processes that the changeover is going to occur;

wherein when all of the signaled processes indicate that they are ready and waiting for the changeover, the node starts new modules and signals the affected processes that the changeover has occurred;

wherein each module starts without affecting normal operation of said node; and

wherein each affected process restarts, if required, without affecting normal operation of said node.

58. An apparatus as recited in claim 57, wherein said node continues with normal operations and notifies said master node that it has completed the software update;

and wherein said master node checks the module dependencies to ensure that any inter-nodal and intra-node dependencies are complete.

59. An apparatus as recited in claim 58, wherein if there are any discrepancies in the inter-nodal and intra-node dependencies, then said master node notifies a user.

60. An apparatus as recited in claim 57, further comprising means for storing, in the software package storage, older versions of a subset of the plurality of software packages and a subset of the plurality of the software modules that are kept for regressing said node back to a previous software module or software package version, wherein when said node does not store the set of one or more software packages in its local persistent storage, then said node can later regress back to previous modules stored in the local persistent storage if it restarts or said master node tells it to regress.

61. An apparatus as recited in claim 56, wherein said node extracts version information and dependency information from the set of one or more software packages and stores the information in its local persistent storage.

62. An apparatus as recited in claim 61, wherein said node compares binary signatures of modules in the set of one or more software packages with corresponding modules stored in the local persistent storage to discover which modules have been updated;

wherein any binary signatures that match indicate that the module has not changed; and

wherein any modules that have different binary signatures replace the corresponding modules stored in the local persistent storage.

63. An apparatus as recited in claim 62, wherein said node runs software package modules by loading the modules from the set of one or more software packages and signals processes that are being replaced by the modules and the affected processes that a changeover is going to occur;

wherein when all of the signaled processes indicate that they are ready and waiting for the changeover, the node starts new modules and signals the affected processes that the changeover has occurred;

wherein each module starts without affecting normal operation of said node; and

wherein each affected process restarts, if required, without affecting normal operation of said node.

64. An apparatus as recited in claim 63, wherein said node continues with normal operations and notifies said master node that it has completed the software update;

and wherein said master node checks dependencies of the set of one or more software packages to ensure that any inter-nodal and intra-node dependencies are complete.

65. An apparatus as recited in claim 64, wherein if there are any discrepancies in the inter-nodal and intra-node dependencies, then said master node notifies a user.

66. An apparatus as recited in claim 55, wherein if more than one node was being updated, the software update will not occur if any node vetoes the software update.

67. An apparatus as recited in claim 55, wherein if said master node receives a veto from said node, then said master node does not update said node and notifies a user that the software update will adversely affect said node.

68. An apparatus as recited in claim 67, further comprising means for receiving an indication to continue updating said node, wherein said master node forces said node to accept the software update.

69. An apparatus as recited in claim 51, further comprising means for initiating the software update by receiving an image containing the software update onto said master node.

70. An apparatus as recited in claim 69, further comprising means for receiving an indication of a set of nodes and a set of software packages that are to be updated.

71. An apparatus as recited in claim 51, wherein the software update contains a list of nodes to be updated.

72. An apparatus as recited in claim 51, wherein the software update contains a list of software packages destined for each node.

73. An apparatus as recited in claim 51, wherein the master node has an ability to categorize nodes into classes where all of the nodes in a particular class of nodes have a same software configuration and may have differing processor types.

74. An apparatus as recited in claim 51, wherein each software package of the plurality of software packages contains version information, dependency information, and other metadata information pertaining to software in the package.

75. An apparatus as recited in claim 74, wherein the other metadata information includes a list of application program interface (API) providers and consumers.