17:00:26 <geoffarnold> #startmeeting mercadorproject
17:00:27 <openstack> Meeting started Fri Jul 31 17:00:26 2015 UTC and is due to finish in 60 minutes.  The chair is geoffarnold. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:28 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:29 <raildo> #... :P
17:00:30 <openstack> The meeting name has been set to 'mercadorproject'
17:00:42 <geoffarnold> Ping?
17:00:53 <raildo> _o_
17:02:12 <geoffarnold> I just uploaded API design notes on the three APIs
17:02:38 <geoffarnold> CLI->Publisher, CLI->Subscriber, Subscriber->Publisher
17:03:01 <geoffarnold> Linked off the wiki page at https://wiki.openstack.org/wiki/Mercador
17:03:17 <raildo> ok
17:03:49 <geoffarnold> We had interesting conversations atHP and within the team at Cisco....
17:04:54 <geoffarnold> I decided to go for a strictly RESTful - i.e. HATEOAS - approach, with a strongly normalized data model
17:05:33 <geoffarnold> This is not in the data path, so API efficiency is less important than cacheability and security
17:06:14 <geoffarnold> So, strict separation between public/immutable resources and those that are ephemeral and/or private
17:06:24 <geoffarnold> No materialized views
17:07:40 <geoffarnold> I also talked with the biz and operations guys, and they emphasized the need to be able to embed the various steps of establishing a federation subscription into a more complex workflow.
17:08:27 <raildo> sure...
17:08:40 <geoffarnold> So, no "do everything" API calls; instead, a stepwise sequence
17:09:28 <raildo> do you already have the API calls defined?
17:09:35 <geoffarnold> We already do that in other parts of our OpenStack deployments.
17:09:50 <raildo> I mean, more then we have in the wiki?
17:10:49 <geoffarnold> API calls yes. See the PDF file. However I won't have the object model finished until later today.
17:10:49 <geoffarnold> And the resources are the heart of the API, of course.
17:11:08 <raildo> ok
17:11:31 <geoffarnold> Had to do it this way, though.
17:11:39 <geoffarnold> Can't define the resources until we have the API call flow
17:11:59 <geoffarnold> Because normalization/caching
17:12:49 <geoffarnold> I'd be curious in your opinions on the design principles listed at the start of the notes, though.
17:13:14 * raildo reading
17:13:31 <geoffarnold> When I was at Amazon, the APIs were hacked together as RPC-over-HTTP
17:13:38 <geoffarnold> They weren't RESTful at all
17:14:30 <raildo> butusing RESTful will be very similiar to other projects in OpenStack, so i like the ideia
17:15:05 <geoffarnold> There are a lot of so-called RESTful APIs that aren't very RESTful
17:16:50 <geoffarnold> A lot of OpenStack APIs rely heavily on resource ID's (i.e. UUIDs) rather than locators (URLs). There's a reason for that, but it implies a lot of shared state
17:22:32 <geoffarnold> Anyway, raildo, let's wrap this meeting up so that I can finish the resource design. I'll upload a new draft later today.
17:22:46 <raildo> geoffarnold: np :)
17:23:04 <geoffarnold> Thanks. Have a good weekend.
17:23:12 <geoffarnold> #endmeeting