<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Dec 2, 2013 at 11:55 AM, Russell Bryant <span dir="ltr"><<a href="mailto:rbryant@redhat.com" target="_blank">rbryant@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">On 12/02/2013 12:46 PM, Monty Taylor wrote:<br>

> On 12/02/2013 11:53 AM, Russell Bryant wrote:<br>
</div><div class="im">>>>  * Scope<br>
>>>  ** Project must have a clear and defined scope<br>
>><br>
>> This is missing<br>
>><br>
>>>  ** Project should not inadvertently duplicate functionality present in other<br>
>>>     OpenStack projects. If they do, they should have a clear plan and timeframe<br>
>>>     to prevent long-term scope duplication.<br>
>>>  ** Project should leverage existing functionality in other OpenStack projects<br>
>>>     as much as possible<br>
>><br>
>> I'm going to hold off on diving into this too far until the scope is<br>
>> clarified.<br>
><br>
> I'm not.<br>
><br>
> *snip*<br>
><br>
<br>
</div>Ok, I can't help it now.<br>
<div class="im"><br>
>><br>
>> The list looks reasonable right now.  Barbican should put migrating to<br>
>> oslo.messaging on the Icehouse roadmap though.<br>
><br>
> *snip*<br>
<br>
</div>Yeahhh ... I looked and even though rpc and notifier are imported, they<br>
do not appear to be used at all.<br>
<div class="im"><br>
>><br>
>> <a href="http://git.openstack.org/cgit/stackforge/barbican/tree/tools/pip-requires" target="_blank">http://git.openstack.org/cgit/stackforge/barbican/tree/tools/pip-requires</a><br>
>><br>
>> It looks like the only item here not in the global requirements is<br>
>> Celery, which is licensed under a 3-clause BSD license.<br>
><br>
> I'd like to address the use of Celery.<br>
><br>
> WTF<br>
><br>
> Barbican has been around for 9 months, which means that it does not<br>
> predate the work that has become oslo.messaging. It doesn't even try. It<br>
> uses a completely different thing.<br>
><br>
> The use of celery needs to be replaced with oslo. Full stop. I do not<br>
> believe it makes any sense to spend further time considering a project<br>
> that's divergent on such a core piece. Which is a shame - because I<br>
> think that Barbican is important and fills an important need and I want<br>
> it to be in. BUT - We don't get to end-run around OpenStack project<br>
> choices by making a new project on the side and then submitting it for<br>
> incubation. It's going to be a pile of suck to fix this I'm sure, and<br>
> I'm sure that it's going to delay getting actually important stuff done<br>
> - but we deal with too much crazy as it is to pull in a non-oslo<br>
> messaging and event substrata.<br>
><span style="color:rgb(34,34,34)"> </span><br></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im">
</div>Yeah, I'm afraid I agree with Monty here.  I didn't really address this<br>
because I was trying to just do a first pass and not go too far into the<br>
tech bits.<br>
<br>
I think such a big divergence is going to be a hard sell for a number of<br>
reasons.  It's a significant dependency that I don't think is justified.<br>
 Further, it won't work in all of the same environments that OpenStack<br>
works in today.  You can't use Celery with all of the same messaging<br>
transports as oslo.messaging (or the older rpc lib).  One example is Qpid.</blockquote><div><br></div><div><div>I feel like I'm trying to read past the rant :) so I'd like to stop an ask for clarification on the exact argument being made. Is the *only* reason that celery should not be used in openstack because it is incapable of being deployed against amqp 1.0 brokers (i.e. qpid).</div>
</div><div><br></div><div>I'm really trying to understand if the actual objection is over the use (or not) of oslo (which seems like something the TC should express an opinion on, if that's the case), but rather about limiting OpenStack's deployment options.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><font color="#888888"><br>
--<br>
Russell Bryant<br>
</font></span><div class=""><div class="h5"><br>
_______________________________________________<br>
OpenStack-TC mailing list<br>
<a href="mailto:OpenStack-TC@lists.openstack.org">OpenStack-TC@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-tc" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-tc</a><br>
</div></div></blockquote></div><div><br></div>-- <br><div><br></div>-Dolph
</div></div>