Jump to: navigation, search


< Meetings
Revision as of 07:36, 29 July 2015 by Slicknik (talk | contribs) (Trove Meeting, July 29, 2015)

Weekly Trove Team Meeting

We have weekly team meetings on Wednesdays at 18:00 UTC in #openstack-meeting-alt

Want to add an agenda item? Please append your item to the upcoming weekly agenda while keeping in mind:

Guidelines for Writing Clear Agenda Items

An agenda item should have a clearly defined objective.

  • [owner/author/interested-party] Good: Review #xxxxx has comments on foobar.py from multiple folks and there seems to be a lack of consensus on how to solve problem ‘y’. Let’s quickly rehash the merits of both approaches in 2-5 minutes and call for a vote. Goal: choose an approach and move forward on implementation.
  • Bad: Discuss blueprint ‘xyz’
  • Bad: Revisit blueprint ‘abc’ that we talked about last week to get answers on remaining disagreements.

When referring to previous conversations or competing viewpoints, be sure to summarize them.

Please make sure to include your own name in the first line of the agenda item, or the name of the person who will be presenting the subject/leading the discussion.

Trove Meeting, July 29, 2015

[cp16net] thoughts here on datastore registration spec

  1. the api should be modeled around the objects so that it makes sense in a restful way
  2. if we need a way to make things even easier like this helper that does multiple calls from a single command this might call for a new api call
  3. calling multiple api call from a single cmd gets the job done but seems wrong

[SlickNik] I'm personally leaning towards having a unified API (create of datastore and datastore-version in a single call). Some of my thoughts on the matter:

  1. This aims for simplifying our API, not simplifying our python-client experience -- simplifying our APIs would implicitly lead to a simpler client experience across all clients -- not just the python-troveclient.
  2. Having a one-to-one mapping between our REST resources and our data-access CRUD objects is not a necessity. It might even be undesirable in this case since it pushes a lot of the logic to the clients and introduces a tighter coupling between the logic on the client and the data access objects on the server.
  3. I've gotten feedback from multiple folks saying that there is currently not much purpose to defining a datastore separate from a datastore version. The experience would be much better if you're just able to define this in a single call.
  4. Having a unified API (datastore, datastore-version in a single call) does not prevent us from, in the future, adding new datastore CRUD calls if we feel like it is an absolute necessity that we must extend properties / metadata at a datastore level.

Meeting Agenda History
Meeting Chat Logs