<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 22, 2016 at 2:57 PM, Dan Smith <span dir="ltr"><<a href="mailto:dms@danplanet.com" target="_blank">dms@danplanet.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> However I do want to point out that cells v2 is not just about dealing<br>
> with scale in the database. The message queue is another consideration,<br>
> and as far as I know there is not an analog to the "distributed<br>
> database" option available for the persistence layer.<br>
<br>
</span>Yeah, it's actually *mostly* about the messaging layer. In fact, if you<br>
don't want to fragment the database, I'm not sure you have to. Thinking<br>
with my Friday brain, I don't actually think it would be a problem if<br>
you configured all the cells (including the cemetery cell) to use the<br>
same actual database, but different queues. Similarly, you should be<br>
able to merge and split cells pretty easily if it's convenient for<br>
whatever reason.<br>
<span class=""><br></span></blockquote><div><br></div><div>This would be a very interesting direction to explore. Focus on the pain points of the message queue and then look at addressing the beast that is the database layer separately. I am going to toss support in behind a lot of what has been said in this thread already. But I really wanted to voice my support for exploring this option if/when we have a bit of time. Not fragmenting the DB unless it's really needed, is a good approach.</div><div><br></div><div>With that all said... I wouldn't want to derail work simply because of a "nice to have" option.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> Additionally with v1 we found that deployers have enjoyed being able to<br>
> group their hardware with cells. Baremetal goes in this cell, SSD filled<br>
> computes over here, and spinning disks over there. And beyond that<br>
> there's the ability to create a cell, fill it with hardware, and then<br>
> test it without plugging it up to the production API. Cells provides an<br>
> entry point for poking at things that isn't available without it.<br>
<br>
</span>People ask me about this all the time. I think it's a bit of a false<br>
impression of what it's for, but the ability to stand up a chunk of new<br>
functionality with a temporary API and then merge it into the larger<br>
deployment is something people seem to like.<br>
<span class="HOEnZb"><font color="#888888"><br>
--Dan<br>
</font></span><div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div><br></div><div>Interesting. I never considered cells to work like a POC environment.</div><div><br></div><div>--Morgan</div></div></div></div>