Skip to content

Technical Cabal Minutes 2012Nov21

Jump to bottom Edit New page
blomquisg edited this page Dec 4, 2012 · 3 revisions

#Attendees

  • Eric Helms (next week secretary)
  • Greg Blomquist
  • Hugh Brock
  • Jason Guidita
  • Martyn Taylor
  • Michal Fojtik
  • Scott Seago
  • Ian Mcleod

Recording

https://www.youtube.com/watch?v=aGkzg7Q4DVs&feature=plcp

NB: we abandoned the hangout about 20 min in due to various hardware problems, so the recording might be rather useless

Old Business

Approve Previous Minutes

Approved (or, not rejected)

Procedural

  • G+ Hangout or IRC (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

  • Secretary for next week ehelms

Tech Topics

  • State changes in the API

    • 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:

  1. Decide how to expose operations vs. strict data updates
    • 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
    • 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
  2. Handling permissions in API calls
    • 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
Add a custom footer
Add a custom sidebar
Clone this wiki locally