[sheepdog] [RFC] REST gateway design choice

[Liu Yuan]

On Mon, Jul 01, 2013 at 09:35:29AM +0900, MORITA Kazutaka wrote:
> At Sun, 30 Jun 2013 17:57:38 +0800,
> Liu Yuan wrote:
> > 
> > Hello list,
> > 
> >       I am writing REST gateway to support HTTP request via fastcgi. There is
> > one fundamental choice regarding where we put the code and both has pros and
> > cons:
> > 
> >  1. bulit-in the code inside the sheep binary
> >     pros:
> >      - share lots of infrastructure code, such as work queue, logger
> 
> We can reuse them like collie and shepherd because they are in the
> lib directory.

work queue need sheep's main-loop while fascgi has its own main-loop and also
work queue doesn't work well since it is not easy to get the information about
sheepdog node without queries.

> 
> >      - simpler interface, just start 'sheep' as usual we gain REST gateway
> >        function, no extra parameter needed.
> 
> I think we need a parameter to enable (or disable) the REST gateway
> for the users who don't use the interface.
> 

I think of always-enable because if people won't use it, it only takes one extra
thread sleeping.

>
> >      - most efficient data transfer between sheep and REST code, no data
> >        transfer at all since they both reside in the same address space.
> 
> I think this is the most important point.  Other softwares like Ceph
> and GlusterFS implements the REST gateway in a standalone binary.  If
> we implement this feature inside the sheep binary, it can be advantage
> for us.
> 

Yeah, this is most important factor to vote for built-in it.

>
> > 
> >     cons:
> >      - if REST code panic, sheep panic. (We might need many code that emulate
> >        swift API that aren't necessarily included in the sheep binary)
> > 
> >  2. put REST gateway code in a standalone binary, switch the pros and cons of
> >     choice 1.
> 
> Overall, I prefer the first one, but I'd like to hear more opinions.
> 

Anyone else?

Thanks
Yuan