Details
| Participant | Role | Time Spent | Comments | Latest Comment |
|---|---|---|---|---|
| Author & Moderator | 5 mins | |||
| Reviewer - 100% complete | 39 mins | 16 | How does this differ from get_service_instance? | |
| Reviewer - 47% complete | 4 mins | |||
| Reviewer - 0% complete | ||||
| Reviewer - 100% complete | 18 mins | 6 | Shorten up some of these long lines as per PEP-8, please | |
| Total | 66 mins | 22 |
Objectives
The registry service uses the object store to implement the backend storage of resource objects. This interface to the data store (commit, checkout, push, pull, clone, diff) should be an interface which can be realized through messaging or used directly as the datastore. The registry itself can be similarly abstracted on top. The resource objects them selves are also a major subject of this review - the current implementation provides a powerful abstraction but does not provide a robust mechanism for recursive or nested objects or lists of element types. This is a serious limitation, but it is intimately tied to the encoding. How do we progress here?
General Comments
07 Jul
Steve Foley says:
Im working on some code for the ResourceAgent that has some generic handling of a resource registry client. Its not perfect, but its a start. Ill get it checked in sometime soon, I hope. I keep getting sidetracked.
|
|
|---|
|
Loading diff...
|
|
|
|---|
|
Loading diff...
|
|
|
|---|
|
Loading diff...
|
|
|
|---|
|
Loading diff...
|
|
|
|---|
|
Loading diff...
|
|
|
|---|
|
Loading diff...
|
|
|
|---|
|
Loading diff...
|
|
|
|---|
|
Loading diff...
|
Eight files is a very large review. Ug.