Open Stack

Hi Georg,

First of all, sorry for the late response. I took a one-week vacation
after the Summit to visit the US.

> Hi Ronan, hi Adrien,
>
> we talked yesterday in the edge/massively distributed working group
> meeting about optimizations of the control traffic between OpenStack
> components. Besides investigating different message busses, we agreed
> that it is also worth looking at how different OpenStack components
> interact. My understanding is that you have already developed tracing
> tools for this.

Actually, we (Inria) developed a tool called EnOS[1] that lets us
conduct performance analysis of different OpenStack deployments.
Briefly, EnOS provides a simple topology definition and traffic shaping
so you can deploy an OpenStack you envision, and then run benchmarking
tools such as Rally (for control plane) and Shaker (for data plane) to
measure OpenStack performance. We made a presentation during the Boston
Summit that shows how we use EnOS to measure OpenStack performance in a
Wide Area Network context[2].

During our experiments, most of the time we struggle to understand the
workflow of OpenStack. Not everybody here is an expert in Nova plus
Neutron plus Glance plus Keystone plus "whatever OpenStack services you
consider in your deployment" so we add into EnOS the ability to produce
OSProfiler traces[3] based on a Rally scenario. OSProfiler is an
OpenStack profiling tool developed by folks of the performance team.
Traces generated by OSProfiler give a fine-grained understanding of your
workflow. Maybe too much fine-grained. Thus, we also developed a tool,
called osp-utils[4], that enables us query an OSProfiler trace (filter,
fold, count...) and automatically produce a sequence diagram to show
interactions between services. You can find examples of such diagrams
that have been automatically generated on the website where we host
results of our experiments[5]. In these sequence diagrams, we choose to
filter calls so that we only keep those that end by an RPC. This is why
there are no interactions with Keystone or with the Database. But you
can also choose to filter or fold on any information available in a
call. Anyway, we believe that such view that clearly states interactions
between services is helpful for the community. We also think that a
query language for OSProfiler traces would help to run some analysis for
the optimizations of the control traffic between OpenStack components.

Please note that osp-utils tool is just a prototype right now -- something
developed during some sleepless nights ;). So the code and documentation
must be improved.

> Nevertheless, one concrete thing which came to my mind, is this proposed
> improvement of the interaction between Nova and Neutron:
> https://review.openstack.org/#/c/390513/
>
> In a nutshell, the idea is that Neutron adds more information to a port
> object so that Nova does not need to make multiple calls to Neutron to
> collect all required networking information. It seems to have stalled
> for the time being, but bringing forward the edge computing use case
> might increase the interest again.

Thanks for pointing such amelioration. This is a good use case to start
with. It should help to understand common patterns in the workflow that
can be optimized. Let's see if we can implement an analysis with
osp-utils that automatically highlight such pattern.

Any comments/remarks on how we can do that is more than welcome.

Best regards,

[1] https://github.com/BeyondTheClouds/enos
[2] https://www.youtube.com/watch?v=xwT08H02Nok
[3] https://osprofiler.readthedocs.io/
[4] https://github.com/BeyondTheClouds/osp-utils
[5] http://enos.irisa.fr/html/seqdiag/v1/

On Thu, May 11, 2017 at 8:44 PM, Georg Kunz <georg.kunz at ericsson.com> wrote:
> Hi Ronan,
>
> hi Adrien,
>
>
>
> we talked yesterday in the edge/massively distributed working group meeting
> about optimizations of the control traffic between OpenStack components.
> Besides investigating different message busses, we agreed that it is also
> worth looking at how different OpenStack components interact. My
> understanding is that you have already developed tracing tools for this.
>
>
>
> Nevertheless, one concrete thing which came to my mind, is this proposed
> improvement of the interaction between Nova and Neutron:
>
> https://review.openstack.org/#/c/390513/
>
>
>
> In a nutshell, the idea is that Neutron adds more information to a port
> object so that Nova does not need to make multiple calls to Neutron to
> collect all required networking information. It seems to have stalled for
> the time being, but bringing forward the edge computing use case might
> increase the interest again.
>
>
>
> Best regards
>
> Georg
>
>
> __________________________________________________________________________
> 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
>

-- 
Ronan-A. Cherrueau