Open Stack

On Mon, Dec 2, 2013 at 11:55 AM, Russell Bryant <rbryant at redhat.com> wrote:

> On 12/02/2013 12:46 PM, Monty Taylor wrote:
> > On 12/02/2013 11:53 AM, Russell Bryant wrote:
> >>>  * Scope
> >>>  ** Project must have a clear and defined scope
> >>
> >> This is missing
> >>
> >>>  ** Project should not inadvertently duplicate functionality present
> in other
> >>>     OpenStack projects. If they do, they should have a clear plan and
> timeframe
> >>>     to prevent long-term scope duplication.
> >>>  ** Project should leverage existing functionality in other OpenStack
> projects
> >>>     as much as possible
> >>
> >> I'm going to hold off on diving into this too far until the scope is
> >> clarified.
> >
> > I'm not.
> >
> > *snip*
> >
>
> Ok, I can't help it now.
>
> >>
> >> The list looks reasonable right now.  Barbican should put migrating to
> >> oslo.messaging on the Icehouse roadmap though.
> >
> > *snip*
>
> Yeahhh ... I looked and even though rpc and notifier are imported, they
> do not appear to be used at all.
>
> >>
> >>
> http://git.openstack.org/cgit/stackforge/barbican/tree/tools/pip-requires
> >>
> >> It looks like the only item here not in the global requirements is
> >> Celery, which is licensed under a 3-clause BSD license.
> >
> > I'd like to address the use of Celery.
> >
> > WTF
> >
> > Barbican has been around for 9 months, which means that it does not
> > predate the work that has become oslo.messaging. It doesn't even try. It
> > uses a completely different thing.
> >
> > The use of celery needs to be replaced with oslo. Full stop. I do not
> > believe it makes any sense to spend further time considering a project
> > that's divergent on such a core piece. Which is a shame - because I
> > think that Barbican is important and fills an important need and I want
> > it to be in. BUT - We don't get to end-run around OpenStack project
> > choices by making a new project on the side and then submitting it for
> > incubation. It's going to be a pile of suck to fix this I'm sure, and
> > I'm sure that it's going to delay getting actually important stuff done
> > - but we deal with too much crazy as it is to pull in a non-oslo
> > messaging and event substrata.
> >
>
Yeah, I'm afraid I agree with Monty here.  I didn't really address this
> because I was trying to just do a first pass and not go too far into the
> tech bits.
>
> I think such a big divergence is going to be a hard sell for a number of
> reasons.  It's a significant dependency that I don't think is justified.
>  Further, it won't work in all of the same environments that OpenStack
> works in today.  You can't use Celery with all of the same messaging
> transports as oslo.messaging (or the older rpc lib).  One example is Qpid.


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).

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.


>
> --
> Russell Bryant
>
> _______________________________________________
> OpenStack-TC mailing list
> OpenStack-TC at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-tc
>

-- 

-Dolph
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131202/ebf1cf11/attachment.html>