-
Notifications
You must be signed in to change notification settings - Fork 6
Technical cabal 27th nov 2012
- Eric Helms (next week secretary)
- Greg Blomquist
- Hugh Brock
- Jason Guidita
- Martyn Taylor
- Michal Fojtik
- Scott Seago
- Ian Mcleod
Approve Previous Minutes Approved (or, not rejected)
(switched to Phone Conf halfway through this mtg b/c of google hangout problems)
- ehelms - hangout
- jayg - irc
- sseago - irc
- mfojtik - hangout
- blomquisg - hangout, but phone is fine
- mtaylor - phoneDo you get
ehelms
####Martyn looked at CIMI
- CIMI is using resources to represent operations
- And a rel attr to represent what will happen to the resource
- Seems more restful than the DC approach
- But probably more than we actually need
Scott: DC - implements part of CIMI, but not part of the DC standard API -> may want to follow that idea (not present it as the "standard" API) -> or, steal ideas from CIMI and implement them in Conductor API Wants to distinguish between the request to actually stop an instance vs. the request to update the state b/c something else stopped an instance -> mtaylor: may be able to distinguish this by looking at the user making the request -> scott: perhaps user isn't the right level of context to inspect for this ... wants to still make it clear via the API call -> mtaylor: still need permissions check to restrict actions/operations by user/role
This breaks down to two separate issues:
- Decide how to expose operations vs. strict data updates a) should Conductor expose an API to "stop" an instance, and the impl. is smart enough to understand the context of the request and make the decision to either stop an instance, or update the instance state b/c of an external action that stopped the instance already b) change the API to represent the two different types of actions; one API endpoint to stop a running instance, and another API endpoint to change the state of a instance represented in Conductor
- Handling permissions in API calls a) some users should not be able to make certain calls regardless of how the API is exposed from part #1 above
- API Versioning
- Not addressed this mtg
- API Paging / Filtering / Sorting
- Not addressed this mtg
- API Race Conditions
- Not addressed this mtg
- Handling Deltacloud exceptions in Deltacloud
- Not addressed this mtg
- Callbacks in Deltacloud
- Not addressed this mtg
New Topics
- API Schemas
- Not addressed this mtg
List Topics: Since we didn't get to many of the topics on the list, and since several of the topics are fairly involved, it was decided to move several of the topics to the mailing list for public discussion. I suspect that this meeting will eventually turn into a place to bring up issues that need further discussion on the list instead of being a meeting where we can resolve tough issues. Occassionally, perhaps we'll resolve an issue after list discussion.
Conductor API
- Handling state changes
- Versioning
- Paging / Filtering / Sorting
- Schemas (martyn to fill in details)
Deltacloud and Conductor
- Handling exceptions in Deltacloud
- Deltacloud callbacks