Open Stack

Hi All,

I too agree from the development point of view, its easier if we have a
single process.
But I was wondering, tempest jobs we run on gate, isn't it better they run
with 3 processes deployed, to make sure it works across processes too?

Just a thought, how about we keep both the options, so that developers can
deploy as single process and on gate we can test it with different
processes?

Best Regards,
Anusha

On 13 September 2016 at 18:10, Aimee Ukasick <aimeeu.opensource at gmail.com>
wrote:

> I completely agree with a single process deployment for DevStack. I
> ran into issues last week with the multiple process configuration
> while I trying to pinpoint an error.  I was using the pdb command line
> debugger to step through Congress and Oslo Messaging, making a call
> from the CLI. More than once the Congress API couldn't find the
> Process Engine, which I'm sure was caused by uploading code and
> stopping/starting services in the wrong order.  Deploying single
> process Congress to DevStack would have saved me a lot of time.
>
> aimee
>
> On Tue, Sep 13, 2016 at 1:42 AM, Masahito MUROI
> <muroi.masahito at lab.ntt.co.jp> wrote:
> > Hi Congress folks,
> >
> > I'm in favor of single process for devstack default. It's easy to check
> > logs and tests its feature.
> >
> > best regards,
> > Masahito
> >
> > On 2016/09/13 11:00, Tim Hinrichs wrote:
> >>
> >> I'd agree with a single process version of Congress for devstack.  I'd
> >> say we should even do that for Newton.
> >>
> >> Tim
> >>
> >> On Mon, Sep 12, 2016 at 6:34 PM Eric K <ekcs.openstack at gmail.com
> >> <mailto:ekcs.openstack at gmail.com>> wrote:
> >>
> >>     Hi all,
> >>
> >>     I want to get people’s thoughts regarding what we should set as
> >>     default devstack deployment config for Ocata.
> >>     At the moment, it is set to deploy three processes: API, policy, and
> >>     datasource-drivers.
> >>
> >>     I see some potential arguments against that:
> >>
> >>      1. For most users installing via devstack, running Congress in
> >>         three processes bring little benefit, but rather a more complex
> >>         and less stable user experience. (Even if our code is perfect,
> >>         rabbitMQ will timeout every now and then)
> >>      2. It’s not clear that we want to officially support separating the
> >>         API from the policy engine at this point. The supported
> >>         deployment options for HAHT do not need it.
> >>
> >>     The main argument I see for deploying three processes by default is
> >>     that we may get more bug reports regarding the multi-process
> >>     deployment that way.
> >>
> >>     Our main options for devstack default are:
> >>     1. Single-process Congress (with in-mem transport).
> >>     2. Two-process Congress API+Policy, datasource-drivers. (other
> >>     breakdowns between two processes are also possible)
> >>     3. Three-process Congress.
> >>
> >>     In the end, I think it’s a trade-off: potentially getting more bug
> >>     reports from users, at the expense of a more complex and less
> >>     polished user experience that could make a poor first impression.
> >>     What does everyone think?
> >>
> >>     Personally, I slightly favor defaulting to single process Congress
> >>     because from a typical devstack user’s perspective, there is little
> >>     reason to run separate processes. In addition, because it is the
> >>     first time we’re releasing our complete architecture overhaul to the
> >>     wild, and it may be a good to default to the least complex
> >>     deployment for the first cycle of the new architecture.
> >>
> >> ____________________________________________________________
> ______________
> >>     OpenStack Development Mailing List (not for usage questions)
> >>     Unsubscribe:
> >>     OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >>     <http://OpenStack-dev-request@lists.openstack.org?subject:
> unsubscribe>
> >>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >>
> >>
> >> ____________________________________________________________
> ______________
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:
> unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >
> >
> > --
> > 室井 雅仁(Masahito MUROI)
> > Software Innovation Center, NTT
> > Tel: +81-422-59-4539
> >
> >
> >
> >
> > ____________________________________________________________
> ______________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160919/b3b9542d/attachment.html>